[postfix-users] real-time accounting - Lösungsansätze?
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
* Christian Bricart postfix-users@de.postfix.org:
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?
policyd.org Version 2 http://policyd.org/v2/ soll sowas bekommen. Ob es schon implementiert ist, kann ich nicht sagen.
p@rick
- 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?
Nö, auch beim END-OF-DATA, wenn die Mail komplett übertragen wurde. Bindest Du den Service dann erst ein, sind aber schon ein paar Mails aussortiert und werden nie vom Policy-Daemon gesehen.
Worum geht's Dir denn? Nur um die Trafficberechnung? Oder willst Du mehr?
Mit demselben Konzept (Policy-Daemon der nur Dunno lieferte, habe ich bei mir allen Mails die Envelope-Informationen im Header ablegen lassen.
Thomas
Thomas Schwenski wrote:
- 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?
Nö, auch beim END-OF-DATA, wenn die Mail komplett übertragen wurde. Bindest Du den Service dann erst ein, sind aber schon ein paar Mails aussortiert und werden nie vom Policy-Daemon gesehen.
d.h. dann doch besser in "smtpd_end_of_data_restrictions" statt in "smtpd_recipient_restrictions"..? in welcher Reihenfolge werden die denn abgeprüft..?
Worum geht's Dir denn? Nur um die Trafficberechnung?
eigentlich (erstmal?) nur den Kunden ne Rechnung schreiben ;-) d.h. nach $recipient_domain aufsummieren...
Oder willst Du mehr?
Mit demselben Konzept (Policy-Daemon der nur Dunno lieferte, habe ich bei mir allen Mails die Envelope-Informationen im Header ablegen lassen.
Christian
Christian Bricart schrieb:
Thomas Schwenski wrote:
- 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?
Nö, auch beim END-OF-DATA, wenn die Mail komplett übertragen wurde. Bindest Du den Service dann erst ein, sind aber schon ein paar Mails aussortiert und werden nie vom Policy-Daemon gesehen.
Abgewiesene Mails in ein Accounting einzubeziehen wäre aber ja auch irgendwie unseriös, geschweige denn dass die Größe nicht zu ermitteln ist ;)
d.h. dann doch besser in "smtpd_end_of_data_restrictions" statt in "smtpd_recipient_restrictions"..? in welcher Reihenfolge werden die denn abgeprüft..?
end_of_data wäre prinzipiell korrekt - hier gibt es aber das Problem, dass dann nicht mehr alle Empfänger zur Verfügung stehen. Ein policy service, der zuverlässiges Accounting leistet, muss also das 'instance' Attribut auswerten, indem er zunächst in den recipient_restrictions die Liste der Empfänger abgreift und dann im end_of_data die Größe ermittelt. Das ist leider nicht ganz trivial und hat auf der englischen Liste schon zu x Anfragen geführt.
Hallo Jan,
Jan P. Kessler schrieb:
end_of_data wäre prinzipiell korrekt - hier gibt es aber das Problem, dass dann nicht mehr alle Empfänger zur Verfügung stehen. Ein policy service, der zuverlässiges Accounting leistet, muss also das 'instance' Attribut auswerten, indem er zunächst in den recipient_restrictions die Liste der Empfänger abgreift und dann im end_of_data die Größe ermittelt. Das ist leider nicht ganz trivial und hat auf der englischen Liste schon zu x Anfragen geführt.
Über den Hinweis bin ich schonmal gestolpert und zu dem selben Schluss gekommen.
Ich verstehe die Ursache nur jetzt nicht so ganz. Vielleicht kannst Du mir das Ganze (dass nicht alle Empfänger zur Verfügung stehen) mal mit einem Beispiel erklären.
Oder anders: Muss ich das so verstehen, dass in den smtpd_recipient_restrictions bei jedem "RCPT TO:" eine Policy-Abfrage stattfindet, in den smtpd_end_of_data_restrictions aber nur noch eine, bei der nur der letzte Empfänger übermittelt wird?
Thomas
Thomas Schwenski schrieb:
Hallo Jan,
Jan P. Kessler schrieb:
end_of_data wäre prinzipiell korrekt - hier gibt es aber das Problem, dass dann nicht mehr alle Empfänger zur Verfügung stehen. Ein policy service, der zuverlässiges Accounting leistet, muss also das 'instance' Attribut auswerten, indem er zunächst in den recipient_restrictions die Liste der Empfänger abgreift und dann im end_of_data die Größe ermittelt. Das ist leider nicht ganz trivial und hat auf der englischen Liste schon zu x Anfragen geführt.
Über den Hinweis bin ich schonmal gestolpert und zu dem selben Schluss gekommen.
Ich verstehe die Ursache nur jetzt nicht so ganz. Vielleicht kannst Du mir das Ganze (dass nicht alle Empfänger zur Verfügung stehen) mal mit einem Beispiel erklären.
Oder anders: Muss ich das so verstehen, dass in den smtpd_recipient_restrictions bei jedem "RCPT TO:" eine Policy-Abfrage stattfindet, in den smtpd_end_of_data_restrictions aber nur noch eine, bei der nur der letzte Empfänger übermittelt wird?
Hallo Thomas,
jup, so scheint es. Siehe auch http://www.postfix.org/SMTPD_POLICY_README.html#protocol
The "recipient" attribute is available only in the "RCPT TO" stage, <soweit so gut> and in the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted ONLY ONE recipient for the current message
Bei einer Mail mit mehreren Empfängern sieht das so aus:
Level: RCPT TO ----------------- Aug 15 08:54:05 mail postfwd-rcpt: [RULES] rule=0, id=TEST, client=test.local[192.168.1.1], sender=test@dom.local, recipient=test01@target.local, helo=<uganda.local>, proto=ESMTP, state=RCPT, delay=0s, hits=TEST, action=dunno Aug 15 08:54:06 mail postfwd-rcpt: [CACHE] rule=0, id=TEST, client=test.local[192.168.1.1], sender=test@dom.local, recipient=test02@target.local, helo=<uganda.local>, proto=ESMTP, state=RCPT, delay=0s, hits=TEST, action=dunno
Level: END-OF-MESSAGE ------------------------------ Aug 15 08:54:05 mail postfwd-eod: [RULES] rule=0, id=TEST, client=test.local[192.168.1.1], sender=test@dom.local, recipient=<>, helo=<uganda.local>, proto=ESMTP, state=RCPT, delay=0s, hits=TEST, action=dunno
Nur ein Call und das recipient Attribut ist leer :(
# postconf mail_version mail_version = 2.5.1
Gruß, Jan
Gruß, Jan
Jan P. Kessler schrieb:
Hallo Thomas,
jup, so scheint es. Siehe auch http://www.postfix.org/SMTPD_POLICY_README.html#protocol
The "recipient" attribute is available only in the "RCPT TO" stage,
<soweit so gut> and in the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted ONLY ONE recipient for the current message
Ich habe das Readme übersetzt, aber ohne Dein Beispiel hab' ich das echt nicht begriffen.
Danke Dir.
Dann ist natürlich klar, dass man um einen doppelten Request an den Policy-Service nicht rumkommt.
Thomas
participants (4)
-
Christian Bricart -
Jan P. Kessler -
Patrick Ben Koetter -
Thomas Schwenski