Levél küldés naplózással

Sziasztok,

Próbálnék egy levél küldő szervert készíteni, ami képes SPF, DKIM kezelésre és mellette real time logol adatbázisba. De szerintem bátran mondhatom, hogy már az elején elakadtam.

Tehát a cél:
- Nem túl nagy terhelésű levél küldő készítése, napi maximum 1000 mail kiküldése. Vannak erősebb és gyenégg napok, de átlagnak vehető az 1000 / nap. Ebből 0db hírlevél, vagy SPAM levél, csak fontos céges, web alkalmazás levelek (regisztráció megerősítés..stb.), automatizált értesítők éjszakánként (pl, meg nem erősített regisztrációk, újboli kiértesítése).
- A lehető legmagasabb fokú SPAM elleni küzdelem beállítható legyen rajta, úgy mint SPF, DKIM
- Csak leveleket kell tudjon küldeni, fogadni nem kell neki semmit. Fogadni egy másik szerver fogadja a leveleket, ez csak kiküld.
- Egy nagyon fontos, ha nem a legfontosabb tulajdonság, pedig, hogy real time tudja naplózni mysql-be a rendszer, hogy ki, kinek mikor mit küldött ki és arra mi volt a címzett szerver válasza. Tehát kb: timestamp, from, to, subject, remote answer... A REAL TIME itt nagyon fontos.

Az elképzelés a következő volt:
- Postfix, mert levél küldésre kiválóan konfigurálható. Bár nagyon sok mást is tud, amire itt nincs szükség, de hát enni nem kér.
- Postfix a SPAM elleni harc esetén is jó választásnak tűnt, mivel SPF, DKIM, mind megoldható nála.
- Majd jött a loggolás... Nah itt megakadtam.
-- Volt a rsyslog, ami tud adatbázisba logolni, de az csak fájl helyett DB-be ír mindent ömlesztve. Ugyan az, mint a syslog-ng, csak nem fájlba ment.
-- Tudnék írni egy scriptet, ami a mail.log fájlt felparsolja, de real time nem tudom, hogyan oldjam meg. Ha a logrotate átfordítja a log fájlt két script futás között, akkor kiesig a köztes esemény a logokból. Illetve, ha nagy, akkor amíg lockolom a fájlt (értsd parsolom), nem tudom, hogy a syslog-ng mit csinál, mert hogy nem vár rám, az biztos.
-- Aztán persze megoldható úgy is, hogy folyamatosan nyitva a fájl, de csak olvasásra, vagyis nincs lock, és figyeli a scipt az új sorokat és logol. De mi van, ha lehal a script, akkor újraindulásig, független, hogy kézi, vagy automatizált, a köztes idő elvész.
-- Köztes megoldás, hogy rsyslog ment adatbázisba és ami a levelezéssel kapcsolatos, azt parsolgatja egy script és kigyűjti belőle, ami nekem kell és a felparsolt sorokat megjelöli egy flaggel, hogy azzal már végzett. De mivel scriptről beszélünk, az sem real time, mert percenként fut a script.

A legjobb az lenne, hogyha lehetne olyat csinálni, hogy a postfix minden levél küldés esetén meghívna egy scriptet, ami a paraméterekből, vagy a postfix által átadott adatok alapján insertálgatná az adatbázis sorokat. A script nem figyel folyamatosan, így nem tud lehalni... A postfix régi motoros, nem hibázik, tehát minden script hívás megtörténne, idővel a script bug mentes lenne, tehát adat vesztés gyakorlatilag 0-ra redukálódna.

Vagy... és most jön az, amiről én nem tudok. Lehet, hogy létezik erre egy tök egyszerű megoldás, csak én még nem hallottam róla.

Bármilyen építő jellegű választ és ötletet szívesen fogadnék.

Köszönettel...

Hozzászólások

Nekünk is hasonló okból (alkalmazás reg és azok megérkezése) merült fel az igény. Első körben néztem Sendgrid, Mailgun és társait. Ezek mind tudjuk a fenti naplózást saját webes felülettel + WebHooks. Viszont a free verziók napi szinten fent vannak valami spam listán, így nekünk nem fért bele a lepattant levelek aránya miatt.

Második körben találtam ezt: https://haraka.github.io/
Tudja mindazt, amit a Postfix (SPF, DKIM). Szerintem kicsit könnyebb is beállítani. Ráadásul könnyedén tudsz hozzá saját plugint csinálni, ami minden eseményre ráállítható, így minden adatrétegre - amit a nodejs támogat - tudsz küldeni részletes logot. Nálunk pl. azt logolja MongodDB-be hogy a fogadó mail szerver átvette-e a levelet.
Ha gondolod át tudom küldeni a plugint, pár sor a lényeg benne valójában.

Minden ingyenes és nem ingyenes megoldást megnéztem, DE:
- Sendgrid szerintem egy átláthatatlan katyvasz lett és egy account alatt nem tud kezelni több webhookot, már pedig nem csak 1 irányba kéne értesítést küldenem, bizonyos eseményeknél.
- Mandrill fizetős lesz április végétől és ráadásul nagyon komoly összeget kérnek el, ha azt is bele veszem, hogy nem minden levelet kézbesít az Ő szervrük sem. Kb 2 évig használtam. (Többlet között ezért lett érdekes a saját megoldás, mert többlet költséget nem szeretnék, vagy legalábbis nem magasat, így a mandrill ugrott, váltanom kell).
- Mandrill után a mailgunra tértem át. Minden jónak tűnt, mindent tud, ami kell és jól is kezelhető. DE 3 domaint vettem fel hozzájuk, amihez 2 külöböző IPt rendelt, melyek közül 1 egyik 2 db spam listán volt fent a másik meg 10 darabon. Ezt pedig úgy vettem észre, hogy a citromail, a freemail mind visszaszórták a leveleket. A gmail.com a statisztikai spam szűrőjével beengedett mindent, amivel teszteltem a szolgáltatót. Hiba volt...

Ezen kívül más SMTP relay nem jöhet szóba, mert kis cégre nem bíznám a leveleim. Létezik még a mailjet és társai, de olyan ingyenes kvótákkal, ami egy vicc, fizertős verzióba meg nagyon komolytalan összegeket egy magyar pénztárcának.

Haraka... Ha nem kapom más olyan választ, amit alap repoból meg lehet oldani, akkor megpróbálkozom vele és akkor érdekelne a sciprt is, mert legalább azzal nem kell küzdeni.

Mi mind mandrillal mind mailgunnal eleg sok levelet kuldunk millios nagysagrend. Viszont kerj fix ip-t akkor tudod felugyelni de shared ip-d van es az spam listara kerul akkor kerj a supportol ujat es tuti fognak adni.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Kértem... Cserébe zárolták (mailgun) néhány domainhez tartozó hozzáférésem, mondván meghaladta a bounced rate az 5%-ot. Amíg nem szóltam nem tűnt fel nekik...

Egy weboldalon regisztráció megerősítéshez használt fiók volt. Kérdem én, hol tehet arról, hogy hülye, aki reggel és rossz címet ad meg. MX rekord ellenőrzésen kívül nem sok minden tudok csinálni. Ami a @ előtt van nem validálható, mert a VERFY minden szerveren tiltott. Vagyis tehetetlen vagyok.

Szóval ennyit a segítőkészséges supportról :(

Már azt sem szabad hagyni, csak visszaigazolt emailcímre érdemes küldeni. Gondold el, hogy egy gmail, egy O365 vagy hasonló méretű szolgáltató könnyedén tudja figyelni az egy feladótól vagy IP-ről jövő maileknél a bounce-rate-et és akár az alapján is szűrni. Ha meg már semmiképp se lehet visszaigazoló linkkel operálni, akkor írni egy validáló scriptet, ami a rcpt to után köszöni és kilép. Így lehet az üres időben nagyon kis intenzítással is ellenőrizni.

dehogynem validalhato. Az MX kotelezove tetele nem teljesen korrekt, mert az is eleg, ha csak A rekordja van. De ezeken tul megnezeheted, hogy 250-et kapsz-e az ehlo, mail from es rcpt to vegen. Ha igen, akkor a cim koser. Ha 45x-et, akkor valoszinuleg szurkelistaba (ugyetlenbe) botlottal. Ha 55x, akkor nem letezik a cimzett. Szoval ha mindezeken tuljutsz, akkor egy megerosito emailt kuldeni, amire ha kattint, reply-ol, whatever, akkor van felveve a cim.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Az eljárásom a zona MX rekordját keresi, mert hogy A rekordja van a domainnek az még nem feltételezi rögtön azt, hogy levelezés is zajlik rajta

A Te eljárásod odáig jó, amíg a gmail.com helyett gmall.com-ot ír a felhasználó. De ha letezik@gmail.com helyett nemletezik@gmail.com-ot ír, akkor már semmivel nem tudod szűrni, csal az első levél küldéssel, aminek megnézed, hogy mi lesz az eredménye: 250, 4xx, 5xx

az en eljarasom vegig jo, mert a 'nemletezik' cim tesztelesenel (tehat nem kell levelet kuldened) 55x hibat illik visszakuldeni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Illik, de nem muszáj. Bőven belefér, hogy az MX csak relayként működik és valójában fogalma sincs a létező az élő e-mail címekről, max. a bounce levelet tudja visszaküldeni, amikor továbbadná...

(rejtett subscribe)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ez a fucked by design minositett esete. Lattam mar ilyet, de attol meg ez nagyon szar, tobb okbol is...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

miert lenne muszaj? El kell magyarazni a hatranyokat, es korreket modon osszerakni az mx-eket...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Nálunk volt olyan setup korábban, hogy a 20-as MX nem intézmény területén volt, hanem az egyetemnél ahonnan a net jött és arra állították be, hogy ha nem megy karbantartás miatt a net nálunk, akkor fogadjon el mindent amit aztán az újra online levélszerver átvett és "megválaszolt".

miert fontos a realtime loggolas? De, felteve, hogy ez tenyleg elengedhetetlen (majd eldol, ha elmagyarazod), akkor csinalhatsz egy primitiv content filtert, ami egy shell script, amit a postfix minden levelnel meghiv, es az elvegzi a loggolast. Ha bovebben kifejted, valoszinu, hogy tudunk erre egy alternativ megoldast ajanlani...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Nem tudom bővebben kifejteni... Sajnos ebbe nem én vagyok a döntés hozó. Ezt az igényt támasztották a rendszerrel szemben.

Gondolom a rendszert használó, aki a logokat nézni fogja kb 2 napig nézi real time, aztán utána évente max 1x nyitja meg az adatokat listázó webet.

De ha ez az igény, akkor sajnos ezt kell megoldani. És ha vitatkozni szeretnék ilyen elképzelésekkel kapcsolatban, akkor a válasz: a holdra is eljutottunk, nehogy már ilyen alap dolgot nem lehet megoldani :((

te mar tapasztaltal ilyet, hogy amikor futott a logrotate, akkor elvesztek elkuldott log bejegyzesek? (En nem). De ha ezen parazol, es napi 1k levelrol van szo, akkor miert nem allitod be a maillog file rotalasat mondjuk fel evre?

Akarhogyis, a fentebb javasolt content filter erre is megoldast ad, raadasul gyerekjatek ott megoldani, hogy minden nap yyyymmdd alaku file-ba irja a logot, amit btw. a syslog-ng is tud, igy nem is kell rotalni a mail logot....

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Nekem logolva van realtime a levelezes, de ez egy mellektermek.
Siman beteszel egy SMTP proxy szervert, es logol az is.
Itt irtam rola bovebben:
http://hup.hu/node/144754

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nézd meg az eximet, azzal megy közvetlenül SQL-be, nem kell külön problémázni. Már az acl szakaszban nagyon könnyű egy szabályt (warn és continue-nak nézz utána) betenni, hogy mi történt a fogadáskor és utána a transport szinten is tudod naplózni. Az biztos, hogy próbálgatós lesz, hogy pontosan milyen állapotokat és hol érdemes naplóznod, amik az eredeti igényhez a legjobban igazodnak.

Az SPF-fel és DKIM-mel is simán megbírkózik az exim, sőt DKIM-mel natívan. :P Bár az SPF nem tudom hogy jön képbe, hiszen csak küldeni akarsz és a küldő MTA-n nem jön képbe az SPF, csak fogadáskor lesz fontos a validálás.

Ennek az exim-nek neki futok holnap, mert az előbb ránéztem a config fájlra és hát cseppet sem éreztem úgy, hogy könnyen konfigurálható. Így elsőre elég semmit mondó paraméter neveket találtak ki. De majd a doksi segít.

Amúgy van ehhez valami jól bevált konfig részlet, ami segíthet a logolásban elindulni? Vagy valami hasonlót feladatot ellátó szabály? Vagy valami, amin el lehet indulni konfigurálásban?

Szerintem ha a postfix-et ismered, akkor inkább maradj annál.

Egyébként elsőként a syslog-ng jutott eszembe.

Második az volt, hogy minden normális *syslog* rávehető arra, hogy logserver-re mentsen, ami triviálisan dolgozhat sql backend-re

Harmadszor elővettem a guglit (postfix log to database), 5. találat ez volt: mysqmail-postfix-logger.

Első olvasásra nem éppen rocket science, de szerintem pont azt tudja amit keresel...

Az első fő tippem, hogy ha debianozol vagy ubuntuzol akkor kukázd a /etc/exim4 alattiakat és írj egy szép exim4.conf -ot. Itt végigvezetnek: http://tldp.org/HOWTO/Spam-Filtering-for-MX/exim-configfile.html

Én anno postfixről váltottam, mert ez a script jellegű konfigolhatóság jobban bejött és nem kellett mindenféle ügyek miatt "jajj tudja-e" irányba menni, hanem eleve komoly eszköztárat ad és lehet írni feltételeket szépszámmal igény szerint.

Logoláshoz példa:


##
# konfigfile elejére, mint deklaráció, az $acl_c_spf -et még a receipt acl-ben állítom be, mikor SPF ellenőrzök, bár nincs érdemi használatban még ebben a formában
##
SPAMSTAT_QUERY = INSERT INTO maillog VALUES ('${quote_mysql:$sender_host_address}', '${quote_mysql:$sender_address}', NOW(), '${quote_mysql:$spam_score_int}', '${quote_mysql:$acl_c_spf}')

##
# valahol később a data acl vége táján: warn mert érdemi befolyása nincs a levél sorsára és azon belül a continue pedig direkt ilyenre van kitalálva
##
warn    !authenticated = *
        !hosts = +relay_hosts
        continue = ${lookup mysql{SPAMSTAT_QUERY}}

Ahogy lentebb írták, gondold meg a postfixről váltást. Ha neked a postfix áll kézre, abban vagy benne, akkor nem biztos, hogy megéri eximre váltással vesződni.

Gentoo-zom... de szerintem ez itt részletkérdés, mert a programok minden disztron ugyan olyanok és ugyan úgy működnek, csak max máshol kell beállítani valamit.

Köszönöm a példákat. Ha eximre esik a választás, akkor mindenképpen hasznát fogom venni.

Mindenképpen meggondolom, mert a postfix configot már értem és tudom mi mit csinál, így nehezemre esik a váltás, de ha nincs más megoldás, akkor megyek. :)

ha csak annyi forintom lenne, ahany sec. bug volt mar (es lesz is meg) a sendmail fucked by design cuccaban, akkor gazdag ember lennek. Bar aligha van elo ember, aki sendmail-t hasznal, amikor van helyette boven alternativa...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szerintem írj egy jó kis ál-policy server-t hozzá...
http://www.postfix.org/SMTPD_POLICY_README.html

A "protocol description" résznél lévőket tudod kiloggolni belőle.

Pl. Így:


#!/bin/bash

# Policy logger

LOGFILE='/tmp/policy.log'

while read input
do
if [ -z "${input}" ]
then
/bin/echo >>${LOGFILE}
/bin/echo -e 'action=dunno\n'
exit 0
fi
/bin/echo ${input} >>${LOGFILE}
done
exit 0

--
Debian Linux rulez... :D
RIP Ian Murdock

ez hibátlanul működik, de a doksi szerint a queue_id benne lesz a kimenetben, de Nekem az nem került bele (vagyis bele kerül a paraméter, csak üres), pedig az már egy nagy segítség lenne, mert akkor a mail.log-ot maradéktalanul fel lehetne parsolni egy scripttel... de sajnos a küldő és a fogadó paraméteren kívül nem sok olyan adat van benne, ami Nekem kéne :(

smtp_sender_restrictions részhez tedd be... check_policy_service felhasználásával... :)

Nálam szépen loggol:

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=ESMTP
client_address=xxx.xxx.64.3
client_name=mail2.xxxxxxxx.hu
reverse_client_name=mail2.xxxxxxx.hu
helo_name=mail2.xxxxxx.hu
sender=info@xxxxxxxxx.hu
recipient=barkas@zzzzzz.hu
recipient_count=0
queue_id=AE64468101847
instance=2480.5705271b.ae5c0.0
size=18168712
etrn_domain=
stress=
sasl_method=
sasl_username=
sasl_sender=
ccert_subject=
ccert_issuer=
ccert_fingerprint=
ccert_pubkey_fingerprint=
encryption_protocol=
encryption_cipher=
encryption_keysize=0

--
Debian Linux rulez... :D
RIP Ian Murdock

jogos... nem a senderhez tettem, így most már nekem is hozta az adatokat

de ettől még csak a queue_id és néhány egyéb adat van meg, de sajnos nem minden...

elkezdtem egy scriptet fejleszteni a logok parsolására, mert úgy látom, eddig ettől jobb megoldás nincs az én legnagyobb sajnálatomra, mert ezt szerettem volna a leginkább elkerülni :(
függetlenül attól, hogy a log fájl szintaxisa adott, ebben van a legnagyobb hiba ráta, már most tudok 3 olyan esetet, amikor hibásan fogja parsolni és egyelőre egyikre sincs megoldásom

A scriptes gondolatodhoz: mi van, hogy ha nem file-ba, hanem named pipe-ba, tehát FIFO-ba történik a logolás, a scripted a másik végén szedi fel az infót? Ez a script egy systemd szolgáltatás, amelyet a systemd újraindít, ha netán megdöglene.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most nézem a scriptemet, amiben használtam named pipe-ot...

Nem ismerem a syslog-ng-t, de gondolom, konfigolható, hogy melyik file-ba írjon. Aztán, ha az a file véletlenül épp egy named pipe, akkor szerintem meg is vagy.

Releváns részleteket írok. Nem azért, mert titok, hanem azért, mert szerintem neked nem lenne türelmed kivadászni a számodra érdekes részeket. Ettől függetlenül, ha gondolod, elküldhetem.

A makefifo() függvényem kap egy nevet, s így hozom létre a fifo-t:

    local FIFO="/tmp/runnerd-fifo.$1/runnerd-fifo"
    rm -Rf "/tmp/runnerd-fifo.$1"
    mkdir "/tmp/runnerd-fifo.$1"
    mkfifo -m 0600 "$FIFO"
    chown "$1:root" "$FIFO"

Aztán van egy ciklusom, amelyben van egy ilyen részlet:

    makefifo "$u" || continue
    FIFO="/tmp/runnerd-fifo.$u/runnerd-fifo"
    exec {fd}<> "$FIFO"
    log "USERS[$i]='$u'\t\tFD[$i]=$fd"
    USERS[i]="$u"
    FD[i++]="$fd"

A log() nyilván logol, ne törődj vele. Az FD[@] tömbömben tárolódnak a file descriptorok, ezt az exec hozta létre.

Aztán van két egymásba ágyazott ciklusom, amelyek így kezdődnek, itt a writer nevű változó nem lesz túl érdekes neked:

    ptr=0
    while [ $ptr -lt ${#USERS[@]} ]; do
        FIFO="/tmp/runnerd-fifo.${USERS[ptr]}/runnerd-fifo"
        LOCK="/tmp/runnerd-fifo.${USERS[ptr]}/lock"
        writer="`stat -c '%U' \"$FIFO\"`"
        while [ ! -e "$LOCK" ] && read -t 0.1 -u ${FD[ptr]}; do
            [ -z "$REPLY" ] && break

Ja, és az írás lemaradt:

FIFO="/tmp/runnerd-fifo.$USER/runnerd-fifo"
exec {FD}<> "$FIFO"

echo -e "$s" >&$FD

Közte vannak kódrészek, de most az nem érdekes. Systemd unit file-ban az újraindíthatóság:

[Service]
Type=simple
Nice=19
ExecStart=/usr/local/bin/tescripted
Restart=always

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon szépen köszönöm a sok hozzászólást és javaslatot.

Leírom, hogy mi lett a megoldás, ami mostanra működni látszik:
- A dolog lényege a napló fájl elemzése, de hogy ez működjön, egy-két dolgot be kellett állítanom.
- Először is a syslog-ng egy a szokásos mail.err, mail.log, mail.warn, mail.info fájlokon kívül egy másik fájlba is logol, ami csak parsolási célokra használok. Így a tényleges postfix logolást nem akadályozza semmiféle script.
- Ezen felül a syslog-ng-nek még megadtam egy formátumot, hogy hogyan formázza ezt a külön fájlt - természetesen, ahogy a legkönnyebb volt feldolgozni.
- Illetve a postfix-nél beállítottam egy fejléc ellenőrzést, ahol a Subject sort lelogolja fájlba.
- Végül egy-két finom hangolás a postfix-en és már csak a script volt hátra.

- A script percenként fut, ami még elfogadható késleltetés volt. Átnevezi a log fájlt, majd újra loadolja a syslog-ng-t, hogy az átnevezett fájl újra generálódjon. Ezt követően a script a postfix logolási logikája alapján soronként feldolgozza a bejegyzéseket. Azoknál az üzeneteknél, ahol megtalálja a queueId: removed sort, vagyis a mailq-ból kikerült levél, azt lelogolja, ahol pedig nem, ott az addig gyűjtött adatokat ideiglenesen letárolja. Mivel addig nincs kiküldve a levél, amíg a queue-ból ki nem került, így nem lehet róla minden infót tudni. Pl: postgray miatti visszafordítás. Így aztán a postfi teszi a dolgát és amikor lejár a lifetime, vagy amikor sikerül kiküldeni a levelet, akkor removed sor megjelenik és már megy is a log táblába az üzenet összes addig begyűjtött adata.

A dolog működik és ahogy eddig figyeltem, még nem hibázott...

Nagyon szépen köszönök mindenkinek mindent, nagyon sokat okultam ebből a topikból és a probléma és megoldódni látszik.

Szia,

Erről nem akarsz egy részletesebb leírást írni? Nem szájbarágósat, csak a lényeget, minden ponthoz a releváns 1-2 sor.

Ugyanakkor a log átnevezést én se tartom jó ötletnek, a percenkénti futtatás helyett szerintem egy "tail -f"-fel simán olvashatnád folyamatosan a logfile-t, a kapott eredményt pedig folyamatosan is feldolgozhatnád.

Ebbe az átnevezős dologba sokan belekötöttek és tényleg nem jó. Ne bántsd az eredeti logfájlt, csak jegyezd meg (pl. sor szám fájlba írása) melyik sornál hagytad abba és legközelebb (1 perc) múlva csak onnan dolgozd fel. (normál logrotate esemény ellen nem véd, azt is külön figyelembe kell venni.)