* 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