e-mail deduplikálás

Fórumok

Olyat tervezek kigondolni, hogy a cégnél kissé megvariálom a levelezést. Jelenleg probléma, hogy a projectek levelei vagy több embernél is megvannak vagy épp csak egynél. Ez mondjuk akkor érdekes, amikor valamelyik kolléga kilép.

Erre találtam a dovecot esetén a shared mailbox dolgot, ami remek.

Hasznos lenne pár project levelezését ilyenbe átköltöztetni, viszont mivel egy-egy levelet valószínűleg nem csak egy címzett kap(ott) meg, ezért hamar előállhat a helyzet, hogy egy ilyen folderben hatszor is megvan Frank Abagnale levele, miszerint "OK" vagy hasonló.

Tehát meg kéne szüntetni a duplikációkat. A google ilyesmire rettenetesen sok dolgot tud javasolni, ezért kérdezek inkább itt, hogy egyrészt csinált-e valaki ilyet, másrészt ha igen, akkor hogyan? :D

Az se lenne utolsó dolog, ha ez a deduplikáció nem csak költözéskor, hanem állandóan futhatna, így ha Józsi és Sanyi is kap egy-egy levelet és mindketten (akár filterrel) átteszik ebbe a folderbe a levelet, akkor csak az egyik marad meg. Ez persze felveti a kérdést, hogy wtf akkor, ha kérdésessé válik, hogy egyik vagy másik emberke megkapta a levelet. Vagy ezt nem technikai hanem munkamódszeri problémának vesszük és egyéb módon (pl. mindig az adott project felelőse kapja a leveleket és Ő filterezi szét) tekintjük, ezért is érdekes, hogy valaki csinál-e ilyet és ha igen, akkor hogyan (nem csupán technikai szempontból vizsgálva a).

A környezet dovecot, maildir, alighanem per user seen, de mielőtt hozzáfognék kérdezek.

Hozzászólások

A Redmine ha jól látom projektek kezelésére való. A wikipédia alapján nincs email kezelő modulja, amivel épeszűn meg lehetne oldani ezt a problémát. A jelenleg használt egroupware sem alkalmas erre.

Persze, azt lehetne, hogy minden levelet feltöltenek az emberek a projektmenedzser vagy dokumentumtár rendszerünkbe, de ez kényelemben sehol sincs a shared folderekhez képest.

Projekt szinten nem emailezni kell, hanem a projektmanagement szoftver eszközeit (wiki, forum, stb...) használni. Legalábbis ez lenne az ideális eset. Az, hogy nálatok ez működik vagy sem, az egy más kérdés :)

Dedup témában én amúgy a block-level dedup-ot javasolnám inkább.

--
Gábriel Ákos
http://i-logic.hu

Mondjuk ez *erosen* levelezesfuggo. A kernel listan keves melleklet van, mig lattam olyan ceges levelezest, ahol meg massziv mellekletek vannak a levelekben.

Bar az is erdekes, hogy a blokkszintu dedup mit tud kezdeni pl. azzal, ha ugyanazt a kis levelet, ld. kernel lista, elkuldod 2x? Ami nyilvan nem ugyanaz a level a fejlec miatt...

Diktatorok kezikonyve

Bocs... :D

De valahol azt gondolom, hogy van értelme a deduplikálásnak, csak sajnos nem azokkal az eszközökkel, amik jelenleg adottak...
- Block szinten szerintem nem lehet deduplikálni.
- Minden levélben van "számottevően" olyan információ, amit lehetne deduplikálni... (Fejlécek, aláírások, mellákletek stb.)
- Ugyanakkor ezt szerintem csak fájlrendszer szintjén érdemes megoldani...
- Az ideális esetet meg nem fogod a való életben létrehozni... Mindig lesz valaki, aki másképp gondolja... :D

--
Debian Linux rulez... :D

Minden levélben van "számottevően" olyan információ, amit lehetne deduplikálni... (Fejlécek, aláírások, mellákletek stb.)

van, csak nem mindegy, mennyit kuzdesz mondjuk egy inline alairas vagy fejlec deduplikacioval. Szerintem kb. egy termek nem tamogatja ezt. Ill. a fejlec imho pont nem jo pelda a deduplikalhato adatokra...

Diktatorok kezikonyve

Egy partner cégünknél "mivel haladni kell a korral", olyan aláírások vannak bevezetve, amik a legkissebb méretükben is 12KB-osak... (képek vannak benne.)
Ez már megéri a figyelmet...
Fejlécben arra gondoltam, hogy pl. a vírusirtók általában közel azonos fejléceket tesznek bele a levélbe, illetve egy adott postafiókba nem sok féle címzett mező van...
--
Debian Linux rulez... :D

Pár gondolat... (Én is agyaltam hasonló kérdéseken. IMAP kiszolgálóval.)

- "A" küld egy levelet "B"-nek ÉS "C"-nek. Ekkor a két ("B" és "C") postafiókban nem lesznek ugyanazok byte-ról byte-ra a levelek...
- "B" átmásolja egyik almappából a másik almappába ugyanazt a levelet. A két levél byte-ról byte-ra ugyanaz...
- "B" visszamásolja az előbbi levelet az eredetie mappába. Az eredeti levél már három helyen található meg, byte-ról bájt-ra azonos formában...
- "B" továbbítja "C"-nek a levelet. Az eredeti levél nagy része belekerül az új levélbe, amit elment az elküldött levelek mappában, és beérkezik "C" új üzenetei közé...

--
Debian Linux rulez... :D

A napközbeni agyalásom vége az lett, hogy lehet hogy nem is technikai oldalról kell megfogni a dolgot. Gondolom mindenki számára ismerős a dolog, hogy minden, az adott projectet érintő e-mailt el kell küldeni a projectmanagernek (is). Ez az ember az, aki felel azért, hogy a levelek bekerüljenek a közös mappába, betegsége, szabadsága esetén pedig a helyettese.

A meglévő levelek esetében viszont:

- vagy találunk ügyes dedup szoftvert
- vagy marad így ahogy van, kb. úgyis csak a jelenlegi projectmanagerek levelezéséből kell beilleszteni dolgokat, ha duplikáció áll elő hát ígyjárás (a duplikáció jelenleg is megvan, tehát nem lesz rosszabb a helyzet), esetleg az unalmas, téli estékre megkapja valaki a nemes feladatot, hogy a duplikált leveleket kiszűrje.

ha nem akarod a kozos folderben 6x latni xy "OK" levelet, akkor Message-ID-re csekkolnek. Btw. email archivalas nem jatszik? Mert a a dedup mellett meg tomoritessel is sporolna a helyen, tovabba a levelekbe nvalo keresesben nagyon eros, amit (foleg) egy projekt menedzser valoszinuleg tudna ertekelni...

Diktatorok kezikonyve

Igen, a message ID volt az, ami elsőnek eszembe jutott mint dedup feltétel, de erre írnom kéne egy valamit, amiben maga a dedup nem nagy puki, inkább maga a maildir közvetlen matatása amit kerülnék ha lehet (nem feltétlen tartom jó ötletnek imap-on keresztül kiszűrni a duplikációkat :D), bár most, hogy rákerestem, találtam pl. ilyet:

https://addons.mozilla.org/en-us/thunderbird/addon/remove-duplicate-mes…

A levelekben való keresésre pedig ott a webmail, thunderbird vagy ha nagyon-nagyon komoly dolog van, akkor a lurker. A helyspórolás jelenleg nem szempont, kb. 130G a teljes levelezésünk, és tippre max. 30G érintett a problémában (de lehet hogy a 3G közelebbi becslés, mert nem az összes projectet érintené a dolog, hanem csak párat - lehet hogy egyelőre, lehet hogy örökre).

Nem értem igazán, mit szeretnél, bocs az értetlenkedésért. Az azonos ID-jű emailek megkeresése Maildir formátumban egyszerű, egy shellscripttel átnyálazod az összes emailt és építesz belőlük valami plaintext listát. Ha milliárd levél van, akkor mondjuk egyből sql-be tolod az adatokat.
A kérdés inkább az, hogy utána mit csinálsz? Megvannak az azonos levelek és simán kiemeled őket az userek postafiókjaiból, ez eddig oké. De mi alapján teszed be őket valahova? Public mailboxokat akarsz vagy egy adott user shared mappájába kerüljön az összes? De akkor meg hogy osztod el a jogosultságokat email szinten, ki melyiket láthassa?

Mivel nem is az eleje a kérdéses (csak annyiból, hogy nem feltétlen akartam kézzel matatni a maildirt, mert a dovecotnak van valami indexe, amit jobb lenne update-elni, de ez a kérdés már megoldódott), ezért a második fele: a dovecot tud shared mailboxokat. Többféleképp meg lehet oldani, és az is megoldható, hogy per user működjön a seen, azaz attól, hogy az A user látta a levelet, attól még a B usernek olvasatlan marad. A jogosultságokat nyilván nem email szinten kellene kezelni, annak semmi értelme nincs, hanem mailboxonként, ott meg a dovecot acl-jeivel lehet megoldani. Sajnos csak text backendje van, de ahogy néztem azt az acl fájlt némi ügyeskedéssel le tudom gyártani az ldap csoporttagságok alapján.

Namost itt jön az, amit szerintem félreértesz. Ha a cég kap egy megbízást fluxuskondenzátor készítésére (azaz egy olyat, ami sokáig tart, több ember fog érinteni), akkor létrehozok egy FluxCapacitor nevű csoportot és mappát, az érintett usereket beleteszem a csoportba, a script legyártja az acl-t, és innentől kezdve az adott projekten dolgozó összes munkatársnak van egy közös levéltára. Ha új kolléga csatlakozik akkor Ő is látja a régi leveleket (is), a egy kolléga másik projektre kerül akkor nincs para, hogy az Ő levelezésében nem marad-e olyan, ami kellene a többieknek (feltéve persze ha minden szükséges levelet eltett a projekt levelezésébe, de ez már nem technikai probléma).

A deduplikáció ott jön képbe, hogy ha a régi, tényleg 5-6 éve futó projektek levelei, amik gyakorlatilag már minden munkatársnál ott vannak szétszórva egy helyre kerülnének, és nyilván lenne közte nem kevés egyezés (pláne az amerikai partnerek szeretik CC-ben elküldeni a fél világnak a leveleiket). Ezeket kellene úgy megfésülni, hogy érdemi információ ne vesszen el. Reménykedem, hogy a message ID nem fog változni valami hülye okból kifolyólag, vagy nem az összes levélnél.

Te a shared mailboxot magyarázod a jövőbeli projektekre. Ez működik, nem is ez az érdekes. Én a múltról kérdeztem, amire részben válaszoltál: egy új mailboxot készítesz minden egyes régi projekt számára és azt osztod ki az usereknek. De hogy fogod ezeket szétválogatni, mert egyesével megcsinálni, főleg ha sok projekt volt az elég húzós. Mire gondolok:

Ha ezek az adataid lesznek meg a végén, hogy válogatod szét az emaileket valójában? Főleg ha a főnök mindenről kap cc-t, még olyan emailekről is, amik nem is projekthez tartoznak.

Végképp elvesztettem a fonalat :)

A terv:

- létrehozom a shared foldert (jelenleg két olyan project van aminél tuti lenne értelme és tippre tíz alatt van azon projectek száma ahol esetleg lehet)
- megcsinálom az acl-eket
- körbeírok az érintett embereknek, hogy vegyél fel a foldert, vagy én felveszem hozzájuk (inkább az utóbbi)
- körbeírok az érintett embereknek, hogy dobálják bele az adott projecthez tartozó leveleket (alighanem ez a válasz a kérdésedre), ami nem nagy hőstett, mert kb. mindenkinél amúgy is külön folderben vannak a.
- miután ez megvan, a project lead (vagy én) a TB pluginnel kiszűri a duplikációkat(*)
- ellenőrzés, ellenőrzés, ellenőrzés
- eredménytől függően pezsgő vagy whisky.

*) a project lead lenne az ideális, mert akkor ő később is tudná így fésülgetni a leveleket. Igaz ha nem ötezer levelet kell átnézni, hanem a napi 1-20 között valamennyit, akkor jóval könnyebb észrevenni, ha már egy levél ott van a folderben.

Jól van....igen, a régi projektekről kérdeztem és ez volt a válasz és egyben a legnyilvánvalóbb is, de nekem nem jutott eszembe: csinálják meg a felhasználók maguknak. :D Kicsit olyan ez, mint amikor megkérdezték tőlem egy felvételi teszten, hogy miért kerek a csatornafedél... minden eszembe jutott, de a nyilvánvaló válasz nem. Tanulság: nem kell bonyolítani, ami egyszerűen is megoldható.

Itt egy email archiváló cucc, ami nem teljesen az amit szeretnél, de támadja az alap problémát.
mailpiler honlap
Ráadásul "HUP közeli" fejlesztés.

Csak érdekességképp: a Wired News leveleiben a 4989.emissary.id@alerts.com message id szerepel hónapokon keresztül. Esetleg valaki más is meg tudja ez erősíteni. Nem mintha ez valós probléma lenne, legalábbis a jelen esetben.

Ez az ID elég gáz téma. Nem csak ilyen lehet az msg id, hanem ilyen is:
2011000079@Szuperkft
Sőt ilyen is:
94f82272-5fbe-427b-8401-a7cfc6d47aa2
Az a helyzet, hogy ezeket a küldő host úgy generálja le, ahogy neki tetszik. Ez utóbbiakra a a spamassasin pl. ezt mondja:
3.0 INVALID_MSGID Message-Id is not valid, according to RFC 2822

Nem tudom, hogy ez vajon segít-e bármiben, de ahol most dolgozom, ott pl. az történik, hogy van egy projekt emailcím, ami egy disztribúciós lista, tartalmazza az összes projekt tag címét.

Amit erre a címre küld valaki, azt nem csak mindenki megkapja, de emellett egy közös folderbe is bekerül (ahonnan egyébként nem lehet törölni).

Ha csak én levelezek az ügyféllel vagy valamelyik másik projekt taggal, akkor arról nem lesz másoknak másolata és nem kerül be a közös folderbe sem.

Ilyen szempontból más, mint amit eredetileg kérdeztél. Cserébe nem kell hozzá varázsolni.
És persze ha valamit levélváltás eredményét mindenkinek meg szeretnénk mutatni (és archiválni), akkor forward a projekt emailcímnek.