Postfix check_policy_service vs. content_filter

Sziasztok

1.
A kettő között mi a markáns különbség?
Oké, más a return szintaktikája. Talán más a bemenő tömb is, de mi az a különbség aminek tudatában egyértelműen dönteni tudsz, hogy adott feladatot melyikben oldd meg?

Keresem, kutatom, de nem találok erről szóló összehasonlítást.

Volt, hogy adott feladatot láttam már mindkét helyen megoldva.

2.
Eddig csak check_policy_service-t alkalmaztam adott porton. Ez egy perl script és a hibája, hogy nagy terhelésnél néha kiakad, így egy másik script figyeli és ismét elindítja a daemonját.

Most egy olyan scriptet találtam ami master.cf-ben definiált service, erre hivatkozok a main.cf-ben. Úgy látom, hogy ezt postfix startnál elindítja, abban futásidőben változtatni nem lehet a scriptben.. Így pl. egy "print LOG $time: $msg" esetén a $time változó alapból nem frissül, ha a script elején adok neki értéket.

Nekem egy olyan megoldás kellene, ami smtp becsatlakozáskor lefuttat egy scriptet, mely néhány paramétert kiértékel (eddig elküldött levélszám, elküldendő levél mérete) és ez alapján az adott levelet visszautasítja vagy tovább engedi.

Nem a kód kitalálása a kérdés, az megvan. A keret a kérdés, hogy mibe lenne célszerű átültetni, hogy a leghibatűrőbb legyen.
Nem hiszem, hogy ehhez feltétlen daemonnak kell futnia. Az én olvasatomban a legegyszerűbb megoldás: van egy bash/perl script ami bemenő adatokkal lefut, kimenőben "OK, nem OK" válasszal. Ennyi.

Tud ilyet a postfix?

Köszönöm!

Hozzászólások

Közben teszteltem a linkelt scripttel a master.cf-ben rögzített policy-t.
Az egyik feltételnél exit 1-re futtattam a scriptet. Server config hibát dobott kliens oldalon, de újraküldésnél a postfix ismét elindította a scriptet (és másik feltételnél el is küldte a levelet beavatkozás nélkül).
Szóval azzal, hogy nem ip:porton fut, hanem master.cf-ben van, a postfix felügyeli és ha elhasal, talpra állítja. Ez biztató.