Tach zusammen,
der "normale" Weg eine Auswertung des Mailtraffics zu machen ist ja entweder: - periodisch (z.B. per cron-daily nach dem Logrotate) das Postfix-Logfile durch einen Parser zu schicken und irgendwie auszuwerten (der "pflogsumm"-Ansatz) oder: - einen "tail -f"-Prozess laufen zu haben, der das Logfile verfolgt und neue Einträge parsed und verarbeitet (der "mailgraph"-Ansatz). oder: - bspw. syslog-ng als syslogd zu verwenden, dort einen Filter zu definieren und eine Destination einzutragen, die mit den Werten dann etwas tut..
Alle Lösungen haben eine Sache gemeinsam - nämlich die Notwendigkeit einen Parser zu haben, der Postfix-Log-Zeilen verstehen und auseinander nehmen kann..
Wenn jetzt jemand auf die wahnwitzige Idee kommen würde, die Daten direkt aus Postfix zu ziehen, wenn sie passieren (und intern in den passenden Variablen stehen) und noch nicht "aufbereitet" sind - was wäre hier der praktikabelste Lösungsansatz?
- check_policy_service in smtpd_recipient_restrictions, der die zum Accounting nötigen Daten[1] verarbeitet und immer "DUNNO" liefert ([1] http://www.postfix.org/SMTPD_POLICY_README.html#protocol) - wobei: ist dort $attr{size} immer sinnvoll gefüllt..? doch nur bei über ESMTP eingelieferte Mails, oder?
- always_bcc / recipient_bcc_maps auf einen Pipe-Mailer, der intern auswertet, wegschreibt und die Mail dann nach /dev/null verwirft
- after-queue / filter: dürfte von der Funktionsweise das selbe wie der BCC-Ansatz sein..
- was ganz anderes?
Christian