Olyan levelezőszervet keresek, amelyik a levélforgalom naplóbejegyzéseit rögtön adatbázisba tudja tárolni.Qmailt üzemeltettem sokáig, és ott merült fel az az igény, hogy gyorsan visszakereshető legyen egy-egy levél sorsa a levelezőszerveren. A Qmail horrorisztikus logjai alapján még konzisztens adatbázis sem állítható össze arról, mi lett egy beérkezett vagy bentről indult levél sorsa.
Ezek után egy új levelezőszervernél az Eximet választottam, mert úgy tűnt, az a legszabadabban konfigurálható, és sokak által használt levelező. Sajnos azonban ebben sem tudtam azt megvalósítani, hogy a beérkezett levél sorsa rögtön adatbázisba kerüljön naplózásra. Amúgy édes kis levelező, de ennyire mégsem lehet szabadon programozni.
Amennyire én láttam, a postfixnél sem megoldható ez, bár abban annyira nem merültem el, mint az előző kettőben.
Jelenleg naplófájlok alapján tudok információhoz jutni, de ismét egy új levelezőszerver összeállítása előtt állok, és örülnék, ha olyan szervert tudnék használni, amivel már ezt is meg lehet valósítani.
Van valakinek tapasztalata, ötlete, ajánlata ezen a téren?
- 1462 megtekintés
Hozzászólások
Hali,
cPanelbe van ilyen, és ahogy nézem ez a rész perl cuccosok. Szóval onnét tudsz "ötletet meríteni".
- A hozzászóláshoz be kell jelentkezni
Miért kéne a levelezőszerver dolga legyen az adatbázisba logolás? Miért nem a log service-é (rsyslog/syslog-ng, you name it)?
szerk.: pontosítás.
- A hozzászóláshoz be kell jelentkezni
Az egyik út a syslog-ng és a MySQL-es logolása. A másik út, ha egy spéci exim konfigot csinálsz és igény szerint SQL-be is küldöd ami neked szükséges.
- A hozzászóláshoz be kell jelentkezni
A syslog-ng alatt gondolom, a log üzeneteket kezelhetem egyedileg, de ez gyakorlatilag nem más, mint a logfájl utólagos felolvasása és értelmezése, max gyorsabban?
Én azt szerettem volna, ha az exim levélkezelés folyamán egyedi bejegyzéseket küldhetek egy mysql táblába, hogy épp holt tart a levél. Lehet, hogy nem is a levelezőrendszer logját kellene adatbázisba irányítani, hanem csak olyan levelezőrendszer kellene, ahol én magam adatbázis-bejegyzéseket készíthetek a levélfeldogozás során bármikor.
- A hozzászóláshoz be kell jelentkezni
A levélfeldolgozás 1-2 sec, ha spam+vírus szűrés is van. Milyen folyamatot szeretnél látni? Mire megjelenik, már elavult az infó :)
- A hozzászóláshoz be kell jelentkezni
Emlékeim szerint a postfix bármely folyamata lecserélhető, így csinálhatsz mindenhez egy wrappert ami onnantól azt csinál amit akarsz. Ha tényleg ezt akarod, de szerintem nem akarod. Elég lesz a logok db-be irányítása.
- A hozzászóláshoz be kell jelentkezni
Felhasználó gyakran keresnek levelet. Erre meg kell mondani, mi lett vele, miért nem találja.
A levél beérkezik a szerverünkre. Lehet, hogy mi visszautasítjuk valami miatt. Lehet, hogy befogadjuk, és továbbítjuk. Nála megtelhet a fiók, akkor az a baj. De lehet, hogy nincs baj, le is tölti, és az ő helyi infrastruktúrájában vész el. (Pl.: más is tölti ugyanazt a fiókot.)
Vagy ha rajtunk keresztül küld, akkor is több állapota lehet a levélnek, mígnem fogadja a címzett szervere.
A levélfeldolgozás folyamatát eximben szépen lépésről lépésre le lehet definiálni, ezért vártam azt, hogy minden egyes lépésben majd valahogy bejegyzést is tudok tenni egy adatbázisba, hogy hol tart a levél, mikor, ki honnan küldte, fogadta-e. Még akkor is, ha a letöltési rész már nem exim, amit az exim kezel, azt bejegyeztem volna adatbázisba, és akkor már csak az imap szerver logjaiból kellett volna kiegészíteni. (Persze, ha valaki tud olyan imap szervert, amelyik az imap eseményeket is adatbázisba tudja naplózni, annak is örülnék. De most elsőre az SMTP-vel is megelégednék.)
Ilyenkor érdeklődés esetén csak egy SQL lekérdezés, és kiderül, mikor mi történt a levéllel. Ilyen SQL lekérdezéseket ma is használunk, csak ma logfájlokból bugásszuk ki az adatot a lekérdezéshez. Nem valósidejű és nem szép.
Mivel minden lépésről jó lenne bejegyzés, ha külön wrappert kell írni minden lépéshez, az nem bonyolítja el nagyon?
- A hozzászóláshoz be kell jelentkezni
Hány ilyen kérés van havonta és átlagosan mennyi időbe kerül egy ilyen kérést megválaszolni? Mert nekem ez eléggé "1st world problem"-nek tűnik, hogy kényelmetlen meg minden, de valójában üzletileg nem igazán éri meg megváltoztatni a folyamat. Ugyanis a user bajával foglalkozni kell, és nem látom hogy egy terminál nyitás +ssh +jól paraméterezett grep/zgrep sokkal lassabb lenne, mint egy tetszőleges SQL-bindzsiző nyitás +auth +jól paraméterezett select.
De ha tévednék (vagy nagyon ráérsz) a következők a lehetőségek:
1, *syslog* beállítása, hogy közvetlenül adatbázisba dolgozzon
2, *syslog* marad ahogy eddig, a logokat felolvasod és tolod magad adatbázisba (akár cron-ból, akár tail -f, stb.)
3, írsz valami policy deamon-t (postfix-nél "egyszerű") ami sql-be dolgozik
+1 ha szükséges még bindzsizel még valamit a választott megoldáshoz, kifejezetten az igényeidnek megfelelően (ez lehet sql masszírozástól kezdve a user által elérhető keresőig bármi)
- A hozzászóláshoz be kell jelentkezni
Nem az időről van szó, hanem arról, hogy ha van ilyen levelező, és támogatja ezt, akkor rögtön használnám, mert segít.
Annyira mindenképp szükség van rá, hogy a logolvasást megérte már eddig is megírni, és ha nem támogatja ezt egyik levelező sem, akkor marad a logelemzés.
- A hozzászóláshoz be kell jelentkezni
OOTB ezt nem tudja semmi szerintem.
- A hozzászóláshoz be kell jelentkezni
+1
A syslog lassítana. Sokkal egyszerűbb a postfix+wrapper, amit tényleg könnyű beilleszteni.
(Igaz, a többi levelezőt nem ismerem annyira.)
- A hozzászóláshoz be kell jelentkezni
Elgondolások helyett egy gyors guglizás többet ér: https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog…
Az eximben bármikor tudsz ilyet, van continue opció és kb minden ponton lehet abban egy SQL kveri. Az már más kérdés, hogy ezekhet mindenképp kell egy felület valahogyan, nem biztos, hogy megéri a fáradtságot.
- A hozzászóláshoz be kell jelentkezni
Hát, nem feltétlen erre gondoltam. A logokat bután berakni adatbázisba fájlokból, egy háttér script is meg tudná tenni. A script még értelmezheti is a logot, és csak azt teszi be, amit érdemesnek talál.
Amúgy, hogy az eximben hol tudok adatbázisba írni, és hol nem, ezzel erős fenntartásaim vannak. Ahol tudok, sokszor ott is csak eléggé kiherélten, dummy műveletek segítségével, de sok helyen egyáltalán nem. ... Legalábbis nekem nem sikerült, pedig sokat olvastam utána. Ami persze nem zárja ki, hogy ne lehetne.
Egyébként, ha jól látom, ez a continue csak ACL-ben használható. Egy router döntést vagy egy transport folymatot nem tudom, hogyan lehetne vele adatbázisba írni.
- A hozzászóláshoz be kell jelentkezni
Pont hasonló elgondolás alapján nálam egy daemon született, ami a mail.log -ot figyeli és dolgozza fel. Postfix esetében a QUEUE ID alapján szépen nyomon követhető a levél sorsa
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Akkor összegezve vagy logot olvasok - akár később, akár valós időben -, vagy postfix wrapper. Ez utóbbit nem ismerem, utána fogok nézni. Így ismeretlenül még nem tudom elképzelni, hogy egyetlen wrapper hogyan fog kezelni minden külön állapotot anélkül, hogy külön leprogramoznám, de majd kiderül.
Köszönöm.
- A hozzászóláshoz be kell jelentkezni
Jön e-mail, saját ID-t kap, bekerül DB-be, majd a wrapperek a hozzájuk tartozó funkcióktól függően update-elik az adott ID-hoz tartozó infókat. Ha eldőlt a sorsa a levélnek, akkor lezárod (mert az ID namespace-e kb csak az éppen aktuális levelek között lesz egyedi, hosszabb távon nem).
De nekem bejött ez a daemon-os dolog. Szerintem csak előnye van annak, hogy egy teljesen független rendszer és nem is próbál meg beépülni
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni