Kdo mi cmare do souboru ?

[Jozef Drahovsky (FreeBSD cz)]

Riešil som niečo iné a narazil na ten istý problém.
Ešte keď som sa rozhodoval či sendmail alebo postfix tak som skúšal aj 
rôzne protokoly pre pop a imap.
Problém bol ten, že hoci som si stihol poštu cez pop3 tak aj po hodinách 
sa mi tam už prečítané a vymazané emaily objavili znovu.
Nepomohlo ani vymazanie /var/mail/maibox

Najprv som podozrieval sendmail, potom tunderbird.  Nakoniec som to bol 
ja :)

POP3  je určený pre ťahanie správ z mailboxu do klienta.
Proces len číta a maže spravy, pritom čítanie (príznak a dátum) si 
poznačuje do tela správy.
Klient si ukladá správy u seba do roznych foldrov.
Správy v mailboxe servera spravidla maze po stiahnutí alebo necháva 
niekoľko dní.
Ak sa tam nechajú trvale tak po niekoľko mesiacoch sú tam gigabajty a 
ťahanie nových emailov začne haprovať až zamrzne.
Ak máš dvoch pop3 klientov a každý na inom počítaci alebo mobile, tak si 
navzájom kradnú došlé emaily.
Kto ťahá prvý ten stiahne a vymaže.

IMAP4 je určený pre udržanie správ v mailboxe a ich nálepkovanie príznakmi.
Imap si vytvára  riadiaci blok v maiboxe. Dovecot ho robí textový ako 
fiktívny email spravu s upozornením nemazať, imap-uw ho robí binárny.
Všetky správy sa držia v mailboxe a majú nálepky. Foldre neexistujú.
Klient ma u seba len kópiu mailboxu.
Tento spôsob je ideálny ak chceš pristupovať k mailboxu z rôznych 
počítačov súčastne.
Problém je mazanie a odkladanie správ. Ak mail vymažeš, tak sa stane 
nedostupný u všetkých klientov.
Len málo klientov pre IMAP umožnuje u seba mať lokálny folder do ktorého 
sa dajú maily presunúť, respektíve skopírovať a zo živého mailboxu vymazať.
Tie IMAP klienti ktoré majú uliožiť do archívu (spravidla v mobiloch) 
len dajú nálepku "archiv" ale ostanú v živom mailboxe a ten narastá a 
narastá.
IMAP zvláda dobre vačšie nafúknutie mailboxov ako POP, ale tiež s 
narastajúcim objemom sa spomaľuje.

Teraz k vzniku problémov. Pokiaľ sa neprihlásiš ako klient cez POP3 
alebo IMAP4 tak sa o mailbox zaujíma len sendmail a prihadzuje tam poštu.
V momente aktivovania prvého prihlásenia tak si deamom POP3 aj IMAP4 
načíta celý súbor k sebe, rozindexuje emaily a poskytuje služby.
Sledujú len to, či je nejaký append do suboru, (od sendamilu) ak je, tak 
si refrešnú dáta.

Problém nastáva pri ukončení spojenia na klienta, vtedy deamom (a nie 
hneď) zapíše do mailoxu čo s nim robil (aj len pri čítaní zapisuje 
príznak čítania)
a ak sú dva deamony tak si mailbox navzájom prepisujú.  Zrejme 
programátori nepredpokladali rôzne deamony (aj od roznych výrobcov) do 
jedného mailboxu.

Zistil som, že tento chaos nastáva nielen medzi POP3 a IMAP4 k tomu 
istému mailboxu,
ale aj medzi medzi šifrovaným a nešifrovaným spojením, ale prečo tomu 
tak je už som nezistil.

Na jeden mbox treba ísť len pop alebo imap protokolom, ale aj 
nešifrovane alebo šifrovane a navzájom tieto 4 veci nemiešať, respektíve 
byť si vedomý následkov.

Jozef

p.s. ten blok dát v textovej podobe vyzerá nasledovne:

 >From MAILER_DAEMON  Wed Feb 27 19:30:20 2019
 >Date: Wed, 27 Feb 2019 19:30:20 +0100
 >From: Mail System Internal Data <MAILER-DAEMON@**********>
 >Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
 >Message-ID: <1551292220@**********>
 >X-IMAP: 1549215201 0000000132
 >Status: RO
 >
 >This text is part of the internal format of your mail folder, and is not
 >a real message.  It is created automatically by the mail system software.
 >If deleted, important folder data will be lost, and it will be re-created
 >with the data reset to initial values.


Dňa 25. 5. 2020 o 17:00 Dan Lukes napísal(a):
>
> Pri pristup k mailboxu pouzivam imap-uw - konkretne IMAP protokol, ve 
> variante STARTTLS. Ja vim, to neni udrzovany software, je dokonce az 
> tak stary, ze autor uz ani nezije. Klidne prijmu radu na neco jinyho 
> (ale nechci aby to melo samostatnou databazi uzivatelu, at to jede nad 
> systemovou a format mailboxu a to to idealne ma textovy), ale to neni 
> duvodem proc sem pisu.
>
> Obcas se stane, ze mi to mailbox /var/mail/$username poskodi, a to 
> tak, ze se na zacatku souboru objevi blok binarnich dat. Pravdepodobne 
> to nejak souvisi se soucasnym pristupem vice procesu k tomu souboru - 
> vice IMAPu (kdyz clovek pristupuje k mailboxu z vice nez jedne 
> aplikace/pocitace) pripadne v tom muze hrat roli i sendmail, kdyby 
> zrovna ukladal dalsi email. Binarni data se objevi na zacatku souboru, 
> a nasledne s nim pak nelze pracovat (protoze nema znamy format) dokod 
> to ho neopravim v textovem editoru.
>
> Moje zkusene oko dokonce dokazalo identifikvoat co to je za binarni 
> data - je to sifrovany segment nejake TLSv1.2 komunikace. Mohl by to 
> napriklad klidne byt kus te IMAPs komunikace, ale je to sifrovany, 
> dovnitr nevidim, jistotu nemam.
>
> Takze konecne k dotazu.
>
> Ocenil bych nejaky napad, jak "pri cinu" chytit proces, ktery mi prave 
> zapisuje do souboru. Podminka je jednoducha, konkretni soubor, zapis 
> na zacatek souboru a prvni byte zapisovanych dat neni "F" (protoze F 
> je tam patri spravne, binarni data vzdy zacinaji jinou hodnotou).
>
> Uplne nejlip, kdybych ho pri tom rovnou dokazal zcoredumpovat, protoze 
> tu chybu budu potrebovat orpavit. Pro zacatek ale staci zjistit "kdo".
>
> Neresil jste nekdo neco podobnyho ?
>
> Dan