[postfix-users] Unterschiedliche Dokumentationen zur amavisd-new-Integration
Hallo zusammen,
wenn man sich die folgenden zwei Dokumentationen zur Integration von amavisd-new in Postfix ansieht:
http://www.ijs.si/software/amavisd/README.postfix.html http://postfix.state-of-mind.de/patrick.koetter/amavisd-new/
...dann bemerkt man da doch ein paar Unterschiede. Ich vermute mal, daß das Dokument auf ijs.si älter ist als das auf state-of-mind.de - oder?
Wenn ich mir das ansehe, dann habe ich da ein paar Fragen, von denen ich zwar glaube, daß ich die Antworten kenne, aber mir eben nicht sicher bin (es ist eigentlich nur die Konfiguration des auf Port 10025 laufenden smptd gemeint):
- aus ijs.si: Die Struktur mit mehreren Cleanup-Services - wird ersetzt durch "receive_override_options = no_address_mappings" beim empfangenden smtpd und durch "receive_override_options = no_header_body_checks" im smtpd, in den von amavisd-new aus eingeliefert wird - was ist da mit den canonical map, werden die da auch deaktiviert? - aus ijs.si: die smtpd_client_restrictions finden sich in dem neueren Dokument auf state-of-mind.de nicht mehr - wofür waren die ursprgl.? - das "smtpd_soft_error_limit=1001" für den auf 10025 annehmenden smtpd - ist das bei einer "smtpd_error_sleep_time=0" notwendig? - das Dokument auf auf state-of-mind.de gibt für den auf 10025 empfangenden smtpd in den recieve_override_options ein "no_unknown_recipient_checks" an, setzt aber zusätzlich "local_recipient_maps" und "relay_recipient_maps" leer - ist da nicht eines von beiden doppelt gemoppelt? - das Dokument auf state-of-mind.de gibt für den auf 10025 lauschenden smtpd kein "-o local_header_rewrite_clients=" mehr an. Liegt das daran, daß das nicht erledigt wird, wenn der aus dem Netz empfangende smtpd mit "no_address_mappings" läuft? - was hat es mit dem reject_unath_pipelining auf sich?
Und zu guter Letzt - was ist after-queue Miltern, die den Inhalt der Mail verändern, also z.B. DK(IM)-Header einfügen. Setzt man in der main.cf ein "no_milters" oder besser im auf 10025 lauschenden smtpd?
Die Erklärungen zu den Optionen kann man sich zwar schon aus der Dokumentation raussuchen, aber gerade das mit dem Rewriting von Adressen ist halt doch nicht so wirklich trivial. Bei mir scheint zwar momentan alles zu funktionieren, aber gerade das Verhalten wenn z.B. Sender/Empfänger nicht fully qualified sind und dann append_dot_mydomain etc. angewendet werden, das habe ich noch nicht getestet.
Viele Grüße Stefan
* Stefan Förster postfix-users@de.postfix.org:
Hallo zusammen,
wenn man sich die folgenden zwei Dokumentationen zur Integration von amavisd-new in Postfix ansieht:
http://www.ijs.si/software/amavisd/README.postfix.html http://postfix.state-of-mind.de/patrick.koetter/amavisd-new/
die neueste Version hat Marc wohl nicht online gestellt. Du findest sie in dem Sourcen zu 2.6.
Marc und ich haben sie gemeinsam überarbeitet und alten Ballast über Bord geworfen. Im Moment ist er noch im Urlaub. Ich mail ihn mal an, die online Version zu aktualisieren.
...dann bemerkt man da doch ein paar Unterschiede. Ich vermute mal, daß das Dokument auf ijs.si älter ist als das auf state-of-mind.de - oder?
Hab gerade in paar Stunden auf de.postfix.org rumgehauen und mir fallen die Augen zu ...
Also im Prinzip ist es eigentlich andersrum. Die DE-Version ist älter als die US-Version.
Wenn ich mir das ansehe, dann habe ich da ein paar Fragen, von denen ich zwar glaube, daß ich die Antworten kenne, aber mir eben nicht sicher bin (es ist eigentlich nur die Konfiguration des auf Port 10025 laufenden smptd gemeint):
- aus ijs.si: Die Struktur mit mehreren Cleanup-Services - wird ersetzt durch "receive_override_options = no_address_mappings" beim empfangenden smtpd und durch "receive_override_options = no_header_body_checks" im smtpd, in den von amavisd-new aus eingeliefert wird - was ist da mit den canonical map, werden die da auch deaktiviert?
$ man 5 postconf | less +/no_address_mappings no_address_mappings Disable canonical address mapping, virtual alias map expansion, address masquerading, and automatic BCC (blind carbon-copy) recipients. This is typically specified BEFORE an external con‐ tent filter.
- aus ijs.si: die smtpd_client_restrictions finden sich in dem neueren Dokument auf state-of-mind.de nicht mehr - wofür waren die ursprgl.?
Die Idee war einfach alle Prüfungen fallen zu lassen, die irgendwie schon mal gemacht worden waren, um damit Ressourcen zu sparen und Performance zu gewinnen.
- das "smtpd_soft_error_limit=1001" für den auf 10025 annehmenden smtpd - ist das bei einer "smtpd_error_sleep_time=0" notwendig?
Den amavis Client auf keinen Fall ausbremsen...
- das Dokument auf auf state-of-mind.de gibt für den auf 10025 empfangenden smtpd in den recieve_override_options ein "no_unknown_recipient_checks" an, setzt aber zusätzlich "local_recipient_maps" und "relay_recipient_maps" leer - ist da nicht eines von beiden doppelt gemoppelt?
Da muss ich heute abend passen.
- das Dokument auf state-of-mind.de gibt für den auf 10025 lauschenden smtpd kein "-o local_header_rewrite_clients=" mehr an. Liegt das daran, daß das nicht erledigt wird, wenn der aus dem Netz empfangende smtpd mit "no_address_mappings" läuft?
Da muss ich heute abend passen.
- was hat es mit dem reject_unath_pipelining auf sich?
Und zu guter Letzt - was ist after-queue Miltern, die den Inhalt der Mail verändern, also z.B. DK(IM)-Header einfügen. Setzt man in der main.cf ein "no_milters" oder besser im auf 10025 lauschenden smtpd?
Wo sitzt der DKIM-Milter und wer hat das letzte Wort? Wenn der Milter vor amavis steht, wird amavis die Signatur zertören, ausser Du nutzt amavis 2.6 und der signiert anschliessend die Mail ein zweites Mal.
Der Einfacheit halber entweder DKIM-Milter nach amavis oder also im 10025er einbauen oder es von amavis 2.6 selber machen lassen - der kann nämlich jetzt DKIM.
Die Erklärungen zu den Optionen kann man sich zwar schon aus der Dokumentation raussuchen, aber gerade das mit dem Rewriting von Adressen ist halt doch nicht so wirklich trivial. Bei mir scheint zwar momentan alles zu funktionieren, aber gerade das Verhalten wenn z.B. Sender/Empfänger nicht fully qualified sind und dann append_dot_mydomain etc. angewendet werden, das habe ich noch nicht getestet.
Ablehnen, ablehenen und dann nie annehmen!
Sei ein guter Postbote und nimm keine Mail an, die Du nicht eindeutig zustellen kannst oder zurückgeben kannst. Diese Verschlimmbesserungen mit @$(myorigin) sind die Pest. Schlimmer ist eigentlich nur noch ein Catch-All und sich dann über Spam beschweren ...
p@rick
* Patrick Ben Koetter p@state-of-mind.de wrote:
- Stefan Förster postfix-users@de.postfix.org:
...dann bemerkt man da doch ein paar Unterschiede. Ich vermute mal, daß das Dokument auf ijs.si älter ist als das auf state-of-mind.de - oder?
Hab gerade in paar Stunden auf de.postfix.org rumgehauen und mir fallen die Augen zu ...
Das tut mir echt so leid für EUch beide - ich weiß zu gut, wie das ist, wenn man einen Server dringend braucht aber die HW Mucken macht :-(
Also im Prinzip ist es eigentlich andersrum. Die DE-Version ist älter als die US-Version.
Wenn ich das gewusst hätte...
- aus ijs.si: Die Struktur mit mehreren Cleanup-Services - wird ersetzt durch "receive_override_options = no_address_mappings" beim empfangenden smtpd und durch "receive_override_options = no_header_body_checks" im smtpd, in den von amavisd-new aus eingeliefert wird - was ist da mit den canonical map, werden die da auch deaktiviert?
$ man 5 postconf | less +/no_address_mappings no_address_mappings Disable canonical address mapping, virtual alias map expansion, address masquerading, and automatic BCC (blind carbon-copy) recipients. This is typically specified BEFORE an external con‐ tent filter.
War wohl für mich auch schon spät. Das hätte ich bemerken müssen. Tut mir leid :-(
- aus ijs.si: die smtpd_client_restrictions finden sich in dem
neueren Dokument auf state-of-mind.de nicht mehr - wofür waren die ursprgl.?
Die Idee war einfach alle Prüfungen fallen zu lassen, die irgendwie schon mal gemacht worden waren, um damit Ressourcen zu sparen und Performance zu gewinnen.
Ok - aber warum fügt ihr dann smtpd_client_restrictions ein? Die sind doch normalerweise leer...
- das "smtpd_soft_error_limit=1001" für den auf 10025 annehmenden smtpd - ist das bei einer "smtpd_error_sleep_time=0" notwendig?
Den amavis Client auf keinen Fall ausbremsen...
Das ist mir klar - die Frage war halt, ob smtpd_soft_error_limit überhaupt einen Effekt hat, wenn smtpd_error_sleep_time auf 0 ist.
- das Dokument auf auf state-of-mind.de gibt für den auf 10025 empfangenden smtpd in den recieve_override_options ein "no_unknown_recipient_checks" an, setzt aber zusätzlich "local_recipient_maps" und "relay_recipient_maps" leer - ist da nicht eines von beiden doppelt gemoppelt?
Da muss ich heute abend passen.
Ich hab jetzt etwas gemacht, was ich schon lange machen wollte, nämlich automatisierte Regressions-Tests, wenn ich was an Postfix ändere. Und ich habe im Verhalten der Test-Suite, mit der ich glaube, alle für mich relevanten Fälle abzudecken, keinen Unterschied feststellen können.
Ging es Euch da evt. um den Memory-Footprint?
- das Dokument auf state-of-mind.de gibt für den auf 10025 lauschenden smtpd kein "-o local_header_rewrite_clients=" mehr an. Liegt das daran, daß das nicht erledigt wird, wenn der aus dem Netz empfangende smtpd mit "no_address_mappings" läuft?
Da muss ich heute abend passen.
Ich auch noch. Alles in allem sollte man man jedoch gerad bei Verwendung von virtual_alias_maps oder canonical_maps mal ziemlich genau in die Logs schauen und überprüfen, welche Adressen zu welchem Zeitpunkt sichtbar sind.
- was hat es mit dem reject_unath_pipelining auf sich?
Das frage ich mich ebenfalls immer noch. Ich habe versucht, den amavisd-new-Source zu lesen, aber meine Kenntnisse dafür sind einfach zu gering. Auch hat ein - zugegebenermaßen nur oberflächliches - überfliegen der DOkumentation eigentlich nur ergeben, daß nur dann unathorisiertes Pipelining vorliegen kann, wenn ich dem smtpd explizit verbiete, PIPELINING nach dem EHLO zu announcen, oder wenn ich kein ESMTP benutze.
Und zu guter Letzt - was ist after-queue Miltern, die den Inhalt der Mail verändern, also z.B. DK(IM)-Header einfügen. Setzt man in der main.cf ein "no_milters" oder besser im auf 10025 lauschenden smtpd?
Wo sitzt der DKIM-Milter und wer hat das letzte Wort? Wenn der Milter vor amavis steht, wird amavis die Signatur zertören, ausser Du nutzt amavis 2.6 und der signiert anschliessend die Mail ein zweites Mal.
Der Einfacheit halber entweder DKIM-Milter nach amavis oder also im 10025er einbauen oder es von amavis 2.6 selber machen lassen - der kann nämlich jetzt DKIM.
Ja, also, das habe ich jetzt einfach mal ausprobiert: Während der modernere dkim-milter in der Default-Konfiguration sowieso keine X-Irgendwas oder Received-Header signiert und es ihm deswegen egal ist, wo er sitzt, hat der ältere dk-milter - bzw. die verifizierenden Clients - da Problem, daß er sowohl die X-Virus-Scanned, X-Spam-sonstwas als auch die Received-Header signiert. Da hat man dann natürlich gleich mehrere Optionen, sich die Signatur zu zerschießen. Wenn man den dk-milter also im an localhsot lauschenden smtpd benutzen will, muß man diese Header nicht nur manuell aussortieren sondern ihm auch noch explizit angeben, er möge in die Signatur schreiben, welche Header er signiert. Danke für den Denkanstoß!
Ciao Stefan
* Stefan Förster cite@incertum.net:
Die Idee war einfach alle Prüfungen fallen zu lassen, die irgendwie schon mal gemacht worden waren, um damit Ressourcen zu sparen und Performance zu gewinnen.
Ok - aber warum fügt ihr dann smtpd_client_restrictions ein? Die sind doch normalerweise leer...
normalerweise! Es gibt aber auch Leute die streuen ihre Restrictions in client, sender, helo, usw.
- das "smtpd_soft_error_limit=1001" für den auf 10025 annehmenden smtpd - ist das bei einer "smtpd_error_sleep_time=0" notwendig?
Den amavis Client auf keinen Fall ausbremsen...
Das ist mir klar - die Frage war halt, ob smtpd_soft_error_limit überhaupt einen Effekt hat, wenn smtpd_error_sleep_time auf 0 ist.
Ja, weil nach einigen soft errors die hard errors kommen und dann disconnect :)
Hallo Ralf,
* Ralf Hildebrandt Ralf.Hildebrandt@charite.de wrote:
- Stefan Förster cite@incertum.net:
Die Idee war einfach alle Prüfungen fallen zu lassen, die irgendwie schon mal gemacht worden waren, um damit Ressourcen zu sparen und Performance zu gewinnen.
Ok - aber warum fügt ihr dann smtpd_client_restrictions ein? Die sind doch normalerweise leer...
normalerweise! Es gibt aber auch Leute die streuen ihre Restrictions in client, sender, helo, usw.
Ich habe mich unklar ausgedrückt. Ätere Verisonen enthielten:
-o smtpd_client_restrictions=
neuer Versionen:
-o smtpd_client_restrictions=permit_mynetwords,reject
Diese Veränderung meinte ich. Die Jungs schreiben das ja nicht aus Spaß an der Freude da rein - und eben die "rationale" dahinter würde mich interessieren.
- das "smtpd_soft_error_limit=1001" für den auf 10025 annehmenden smtpd - ist das bei einer "smtpd_error_sleep_time=0" notwendig?
Den amavis Client auf keinen Fall ausbremsen...
Das ist mir klar - die Frage war halt, ob smtpd_soft_error_limit überhaupt einen Effekt hat, wenn smtpd_error_sleep_time auf 0 ist.
Ja, weil nach einigen soft errors die hard errors kommen und dann disconnect :)
Lies nochmal - da steht in beiden Fällen:
-o smtpd_hard_error_limit=1000
Und dann darf ich glaube ich schon nachfragen, ob das aus erzieherischen Gründen gemacht wird, smtpd_soft_error_limit explizit zu sagen, weil das halt eine Beispiel-Anleitung ist, oder ob es da bene Seiteneffekte gibt, die ich nicht kenne.
Ciao Stefan
* Stefan Förster cite@incertum.net:
Ich habe mich unklar ausgedrückt. Ätere Verisonen enthielten:
-o smtpd_client_restrictions=
neuer Versionen:
-o smtpd_client_restrictions=permit_mynetwords,reject
Diese Veränderung meinte ich. Die Jungs schreiben das ja nicht aus Spaß an der Freude da rein - und eben die "rationale" dahinter würde mich interessieren.
Verseh ich nicht. smtpd_client_restrictions= reicht vollkommen hin :)
Hallo Ralf,
* Ralf Hildebrandt Ralf.Hildebrandt@charite.de wrote:
- Stefan Förster cite@incertum.net:
Ich habe mich unklar ausgedrückt. Ätere Verisonen enthielten:
-o smtpd_client_restrictions=
neuer Versionen:
-o smtpd_client_restrictions=permit_mynetwords,reject
Diese Veränderung meinte ich. Die Jungs schreiben das ja nicht aus Spaß an der Freude da rein - und eben die "rationale" dahinter würde mich interessieren.
Verseh ich nicht. smtpd_client_restrictions= reicht vollkommen hin :)
Dann geht's Dir ja wie mir ;-)
Übrigens ist die amavisd-new-Anleitung auch sehr brauchbar, um andere "hochvolumige" smtpd's für spezielle Zwecke, z.B. Mailman-Injection etc., zu konfigurieren ;)
Ciao Stefan
participants (3)
-
Patrick Ben Koetter -
Ralf Hildebrandt -
Stefan Förster