* 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