Sziasztok
Visszatérő probléma: Könyvelő kollegina felhív, hogy növeljem meg a mail tárhely méretét, mert nagy csatolmányokat küldött fontos helyekre és meg kell tartania a kimenő leveleket későbbi bizonyításra, hogy ő elküldte ezeket.
Azt tudjuk, hogy egy mail az elküldött mappában mennyire szimulálható, de ettől most tekintsünk el.
Van valami jobb módja annak prezentálására, hogy adott mail kiment _adott_csatolmánnyal?
Valami olyanra gondolok, hogy a levélbe bejegyzi, hogy különféle SHA1 lenyomatú fájlok xy fájlnévvel csatolásra kerültek.
Ekkor nem volna szükségszerű tárolni a sok megabájtos fontos iratokat a mailben. Küldés után lehetne törölni a csatolmányt és csak a levelet + SHA1 bejegyzést meghagyni.
Első körben kliens oldalon keresem a megoldást: Thunderbird, Roundcube
Ha szerver oldalon lehet vezetni egy összesített listát, akár az is jó lehet, ez esetben Postfix+Dovecot van.
Hozzászólások
Gondolom erre valóak az archiváló rendszerek, ahol minden egyes level külön hash / időbélyeggel ellátva szerepel ameddig arra szükség van. Így ha kell a bizonyíték felcsapja az archiváló szervert, és nem egy imap mappában kell évekig örízgetni a levelet.
Fedora 38, Thinkpad x280
Az archiváló szerver gondolata már többször felmerült. Jó, hogy említetted, +1 indok rá, hogy bevezessük. Van esetleg neked vagy bárki másnak bevált megoldása erre?
Mi a Piler-t használjuk, frankó (mailpiler.org).
MailStore. Saját célra is ezt használjuk, meg egy rakás helyen. Fizetős.
trey @ gépház
Egyetértek, hogy szerencsésebb megoldást is lehetne a leírt problémára találni.
Ettől lineárisan függetlenül azonban sosem értettem, miért kell a júzerek tárhelyét korlátozni. Nálunk szerencsére ez már megszűnt, de korábban gyakran szekáltuk az infrásokat, hogy összedobunk nekik egy vinyóra, csak ne legyen már ez a kínlódás...
Az a vicc, hogy amit archiváltam, azt is ők tárolták, csak utána nekem sokkal nehezebb volt elérni.
Szerintem gáz, amikor egy ingyenes gmail fiók többet nyújt, mint a saját infrastruktúránk.
Az infrásoknak elsősorban nem azzal van bajuk, hogy a userek leveleznek, hanem azzal, hogy a tárhely amit rendszeresen backupolni kell exponenciálisan nő és a felhasználók nem törlik a felesleges leveleket. Tipikusan a barátnőjétől kapott kiscicás videot elküldi még 10 embernek a cégnél és attól kezdve 11 példányban tárolódik amíg a világ világ és a backup egy nap alatt fut le.
Mi mondjuk nem küldözgetünk egymásnak kiscicás videókat a vállalati email-en.
Minket meg ezek az infrás problémák nem érdekelnek. Legyen email, legyen tárhely, mert kell, és kész. Nonszensz, hogy azért ne tudjam végezni a munkám, mert valakinek fáj, hogy meddig fut a backup.
A hálózati meghajtóknál az deal, hogy nem minden könyvtár backup-olódik automatikusan, csak amire kérve van (ilyenkor a gyakoriság és a megőrzési idő is hozzá van rendelve).
Ez szerintem két okból sem reális elvárás. Egyrészt bazinagy a levélforgalom, nincsen erre idő, hogy szelektálgasson az ember.
Másrészt mára az lett a szemlélet, hogy mivel a tárhely már szinte korlátlan és olcsó, mindent is megtartunk. Hogy ez jó vagy rossz hozzáállás-e, erről lehet vitatkozni. Mindenesetre pár GB vagy TB nem fáj ahhoz képest, amikor valami kéne de nincs meg.
Abban teljesen egyetértek Veled, hogy a júzerek egy csomó felesleges szart generálnak, és a legtöbb esetben rengeteg a redundancia is a tárolt adatokban. Mégis azt mondom, hogy gáz, amikor nevetséges kvótákkal próbálunk meg ,,rendet tartani".
A munka szempontjából minden erre fordított idő veszteség.
Pl. nálunk volt, amikor 250 MB volt az inbox kvóta. Aztán lett 1 GB, de ez se hozott nagyságrendi változást. Volt, amikor kényszerített archiválási szabály volt beállítva a 3 hónapnál régebbi levelekre (fú de utáltam).
Egy ideje végre korlátlan az inbox.
Az a vicc, hogy amit átteszek az Archive-ba, azt ugyanúgy tárolni és backup-olni kell az IT-nek, csak még nekem is szarabb.
Talán az nyújthat valami megoldást, ha
- meghatározzátok, ellenőrzitek és betartjátok a megőrzési időt (pl. 5 év), és annak leteltével megy a purgálás
- alapban mindennek rövid a megőrzési ideje, mondjuk 2-3 év (meg kell nézni, törvény mit ír elő), és a júzernek magának kell áttenni hosszú megőrzésű mappába azokat a doksikat, amikre eltérő kötelezettség van
Ez utóbbinak hátránya, hogy ha elfelejti, akkor később a cég is jogilag felelősségre vonható, ha olyan dokumentum veszik el e miatt, aminek megőrzésére törvényi előírás van.
A backup idő- és tárhelyköltsége még mindig a legolcsóbb a cégnek a többi lehetőséggel szemben (amikor a mérnökök ideje pazarlódik), ezért nem törődik vele senki.
Más kérdés, hogy az IT szolgáltatások árazása nem ritkán irreális, haveri (pénzkimentési) alapon fog a ceruza. Azt nekem ne mondja senki, hogy a vinyókat és a vasat megvenni drága párszáz mérnökre és két gyártócsarnokra. Még AWS-be küldeni az egy évnél régebbi cuccot se egy nagy kaland.
Régebben üzemeltettem mail szervert, ott azért kérte a főnökség a kvótákat, hogy ne fordulhasson elő az, hogy egy felhasználó mailboxa akármi okból úgy meghízik, hogy elfogy az eszközön a hely és emiatt a többieknek küldött fontos levelek is visszapattannak.
Akkoriban nem volt szinte ingyen szinte korlátlan tárhely, ha jól emlékszem, néhány 7 GB méretű SCSI hdd-vel kezdtük az egészet, és kb. 15 év alatt kb. tízszeresére nőtt a kapacitás.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Ó, mennyire szeretem, amikor az egy szál gépnél többet soha nem üzemeltető végfelhasználó osztja a tanácsokat üzemeltetésről azoknak, akik évek óta ebből élnek! Persze, ahol tízmillió fociszakértő és tízmillió virológus akad, ott nyilván van tízmillió üzemeltető is :)
"Veszünk a sarki bótbul 40ezeré 2 nagy vinyót, egyik lesz az éles, a másik lesz a mentés, meg hozzá a Tecsóba 50ezerért egy gépet, azon majd elfér minden, oszt jónapot."
Ja. Neked. Otthonra. Se.
Azért a 99.99-hez ez egy kicsit kevés lesz.
Első körben nem árt ugye a RAID, mert azért az is fáj, ha egy napi melód megy a kukába, és a 10-20 órája készült mentésből állunk vissza. És igen, kell mentés is. Az sem árt, ha az is redundáns. Meg jó lenne, ha akkor sem lenne leállás, amikor valami megpusztult, és éppen cserélik.
És persze az sem árt, ha a napi mentés lefut legalább egy nap alatt...
Láttam már olyat, ahol az adatmennyiséghez mérten ehhez a hálózat és/vagy a diszk-rendszerek kevesek voltak. 1TB adat áttolása Gigabites hálón minden overhead nélkül is több mint két óra. Hoppá.
Ha szalagos mentés van, akkor az sem mindegy, hogy elég egy szalag, vagy cserélgetni kell mentés közben. Persze, van olyan rendszer, ami automatikusan megoldja a szalagcseréket is, de hidd el, annak nem akarjátok összedobni zsebből az árát.
De van itt más is. Mondjuk legyen felhasználónként 1 TB igény. Szorozd fel 1000 userrel, aztán találd ki, hogyan pakolsz be ennyit a Tescos PC-be. :)
Olyan apróságokkal már ne is törődjünk, hogy az áram-igény is szépen tud nőni, és az UPS-ek ára sem lineárisan skálázódik.
Ok, nézzünk mást. Felhasználónként őrizzünk mondjuk néhányszor 100.000 levelet.
Nyilván nem lehet egy fájlba rakni, mert akkor baromi lassú lesz törölgetni belőle.
Rendben, legyen minden levél külön file. Próbáld ki, tegyél be egy könyvtárba 100.000 fájlt, majd listázd ki. Hoppá... Pedig te csak egy user vagy az ezerből.
Másik kísérlet: hozz létre egy merevlemezen 1000*100000 fájlt, bármilyen struktúrában. Aztán másold ezt át (még csak nem is kell hálózaton) egy másik lemezre. Utána meséld el, hány napig tartott.
Olyan is előfordulhat ám, hogy az 1TB mailboxokon mondjuk 2-3 user elindít egy fulltext search-öt. És ugye nem lenne jó, hogy amíg az fut, addig a többieknek "akadozik" a levelezés.
Nem mondom, hogy ezek megoldhatatlan problémák, csak nem árt képben lenni vele, hogy ezek nem pofonegyszerű és nem filléres problémák.
És igen, én is láttam már űrhajót, de a sarki boltba a kenyérért többnyire bicajjal járok, vagy gyalog.
Biztos, hogy ugyanúgy, vagy csak azt gondolod? Nem lehet, hogy mondjuk az archive az HDD-ken van, míg az aktív levelezés SSD-ken? Nem lehet, hogy az Archive-ról csak hetente készül mentés, míg a többiről naponta, vagy sűrűbben?
Szerintem meg ha valaki úgy érzi, hogy gondot okoz neki egyáltalán nem elrugaszkodott igényekre megoldást találni, akkor lehet, hogy azt a munkát nem neki kell csinálni. Ne már, hogy 250 MB-ra kell korlátozni a userek inbox-át, nehogy kazettát kelljen cserélni a backup-on...
Aki elvállalja egy ilyen cégcsoport levelezőrendszerének üzemeltetését (elég jó pénzért), az ne sírjon már, hogy miért keres a levelei között a paraszt.
Durva lenne, ha minden email külön fájlban tárolódna. Szerintem valamilyen indexelt konténerben vannak (de nem tudom, ez a konkrét megoldás hogyan működik). Ilyen megoldásokkal mondjuk elhiszem, hogy szopsz.
A "gondot okoz neki egyáltalán nem elrugaszkodott igényekre megoldást találni" egyébként elsődlegesen nem az üzemeltetőknél fogja kicsapni a biztit, ha az az igény jön szembe, hogy mondjuk 1000 postafiókhoz legyen 15GiB/darab tárhely (~15TiB a levelezőrendszer alá, ez még dedup-pal is TiB-os nagyságú terület), hanem annál, akinek az ehhez szükséges erőforrásokat ki köll fizetnie.
1000 usernek I/O igénye is lesz nem kevés, viszont a tárhely egy jelentős részét olyan levelek fogják elvinni, amik ritkán kellenek, úgyhogy a dedup mellé tiering is jó, ha van (ne kelljen a teljes tárkapacitást SSD-kre szétpakolni...), mentéshez is TB-os nagyságrendben kell erőforrást (szalag, mentési időablak, mentőrendszer adatbázisa(!)) allokálni - nem, nem a "nehogy kazettát kelljen cserélni a backup-on" lesz a gond - ekkora méretben robot nélkül nem fog menni, mert vélhetően az 1000 user más rendszereket is használ, amiket szintén menteni kell, amik szintén "termelnek" adatot...
Csak nagyságrendileg, hány felhasználóval és mekkora tárterülettel üzemeltettél, illetve mekkora terhelésekre méreteztél már ilyesmit...?
Nekem évekig volt az a munkám, hogy ezekből próbáljak valami értelmes kompromisszumot kihúzni. 2021 van, kb. az összes generikus IT szolgáltatásra van már megoldás, legtöbbször dobozos, supported, dokumentált formában is. Az, ha a kedves ügyfél nem akarja kifizetni, az PEBKAC, nem technikai limitáció. Ilyenkor szokott kiderülni, hogy mégsem kell a 99,9999%, mégis ki szabad vinni az adatot public cloudba, stb.
Hányszor volt már olyan, hogy az ügyfél álmodott egy nagyot, én megírtam neki a 8-9 számjegyű árajánlatot, ő meg pislogott, mint hal a szatyorban... :)
Szerencsére én csak egy kis irodának az infrastruktúrájáról gondoskodtam. Hamar váltottam is, rájöttem, hogy nem akarom én ezt csinálni.
Na de én nem is vállalkozom ilyesmire és nem jelentkezek be nagy cégekhez, és nem sír a pofám a büdös júzerek miatt.
Ebben a beszélgetésben én a júzer oldalt képviselem (ha eddig nem tűnt fel) picit Baló Gyuri bácsis mímelt naivitással. Mert a mérnökök többségét nem érdekli a rühes szalagod meg a RAID-ed. Sokan azt se tudják, mi az. Csak annyit látnak, hogy 250 MB-ra van korlátozva az inbox, ami miatt szop a napi munkájával, és közben még a gmail is csaknem százszor annyi tárhelyet ad, ,,ingyen".
Ez sajnos ilyen.
Van mondjuk rá egy söröm, hogy nincsen itt napi backup, legfeljebb snapshot.
Sosem értettem ezt a mindent öt off-site helyen kell őrizni szalagon mindennap dolgot. Legfeljebb a könyvelést szükséges szerintem ilyen szinten biztosítani. Az email-eknél imho belefér némi kockázat.
Network drive-oknál meg van tiering, sok mappa nem is backupolt.
Én meg igazából nem értem ezt a szájkaratét. Ezeket az igényeket abszolút meg lehet oldani, amit te akarsz, és ahogy nálatok is működik, csak éppen ára van, amit nagyon sokan nem akarnak kifizetni. Ennyi a történet, semmi több.
Ahogy az előttem szóló is írta, ez leginkább pénz kérdése, amit nem a felhasználók határoznak meg. Nyilván az is kell, hogy az illetékes ismerje a következményeket, legyen, aki érthetően elmondja, ezt a szálat a végtelenségig lehetne boncolni.
Egyébként nem csak a könyvelésre célszerű ráizgulni, mert az tipikusan nem hozza a pénzt a cég számára, de ez cégfüggő (adatvagyon mennyi és milyen formában jelentkezik), a levelezés tipikusan a legfontosabbak közé tartozik.
Nem sír a pofám a büdös júzerek miatt. Nem ők a megrendelők, és nem ők fizetik a számlát, szóval tőlem vinnyoghatnak. :-)
A megrendelővel már gyakrabban akad gond. De ugye, ha 2milláért nem egy S Mercit kaptál, azért sem az autókereskedőt kell szidni.
Tapasztalatom szerint általában az első adatvesztésig szokott "beleférni" a kockázat.
És egy normális cégnél ez megint nem az a kérdés, amit a júzernek kellene eldöntenie.
Levelező szerver függő, hogy miként tárolódnak a levelek. Maildir formátum esetén minden levél egy fájl. Mbox formátum esetén egy mappa egy fájl. Exchange esetén adatbázisok vannak (1-1 fájl napló fájlokkal), egy adatbázisba több postafiók adata kerül.
A Maildir tény, hogy problémás lehet bizonyos esetekben, más esetekben hatékony és/vagy elegendő.
Ettől függetlenül a kolléga sok valós pontot leírt (és mások is), mert a tárhely költsége tipikusan jóval többet jelent 1-1 lemez áránál. Ha van telephelyen kívüli mentés (márpedig célszerű), akkor az internet sávszélesség is meghatározó lehet. Igen, lehet trükközni, optimalizálni, de az megint költség. Egyébként pont ezek azok a pontok, amik miatt tipikusan nem éri meg vállalati levelezést üzemeltetni, mert a felhős megoldások sokkal egyszerűbbek (olcsóbbak, lényegében licenc árban) még akkor is, ha lokális mentésről gondoskodik az ember.
Nem azt állítom, hogy jó a kvóta (ahol van lehetőségem beleszólni, ott nem javaslom), de tény, hogy rengeteg a felesleges szemét adat. A fájlszerveri levelezésen kívül például tárhely zabáló a szkennelés. Hiába törli le (ha letörli), attól még ~1 hónapig benne van a rendszerben. Arról nem is beszélve, hogy az Outlook 50GB fölött kezdi nem jól érezni magát.
Ez kicsit olyan, mikor a szoftverfejlesztők gyártják a szemét kódot azzal a mottóval, hogy az ő ideje sokkal drágább, mint a RAM és a CPU. Pont tegnap hallottam ezzel kapcsolatban egy meredek sztorit: valami adatbázis karbantartó feladat vége még 18 óra után sem látszott, egy fél órás egyeztetést és nyomásgyakorlást követően, minimális munkával sikerült letornázni 20 percre.
Célszerű megnézni, mennyibe kerülnek a CPU-k és a magonkénti licencek. AllFlash tárhely sem az olcsó kategória.
Ezzel óvatosan. A ahogy már leírták, az üzemeltető meg tervező összerakja neked amire igényed van, csak nem fogod tudni kifizetni. Se a kiindulási költséget, se a TCO-t, mert egyszerűen nem éri meg. Nézd meg, hogy pl. felhőéknél mondjuk 50-100GB egy alap mailbox méret, de rögtön juzerenként EUR 5 körül van havonta alapból. Ha van 20 juzered, akkor csak emailre elpuffantasz EUR 100-at és van 20x50G helyed, illetve esetleg a shared meg egyéb mailboxoknak. A felhős megoldás azt is jelenti, hogy _nincs_saját_ mentésed az adatokról és ha a csodás felhőben esetled köd és füst üzemmód jön, akkor pillázik az illető, mindezt évente 400k nettó körüli összegért.
Ki kell ábrándítsalak, jellemzően file alapú a tárolás, ha Linuxos rendszer, ha Exchange akkor spéci file-ok több szerveren elosztva, de ott a licenszdíjtól fogsz hanyattesni (vagy fizeted az előbbi felhőt szépen). Valamilyen szinten persze indexelt, de a fulltextre azért kevéssé.
Aki elvállalja a "cégcsoport" levrendszert, az valszin mond egy fiókmennyiség és adatmennyiséget, amit adott költségkeretből (ez a kulcs ugye...) lehet vinni. Nyilván nem 20x1GB lesz a limit 2021-ben, és a 20x1T fiók az igény, akkor keményen zsebbe kell nyúlnia a megrendelőnek.
A probléma az, hogy amikor jönnek az igényekkel (már megint nem működik c. műsor), akkor nem szokott az eszükbe jutni, hogy igazából azt kapják amiért fizetnek, de pl. 16 millió file-t bazilassú lesz menteni, és külön öröm lehet, ha még archiválást is kérnek.
Majdnem bedőltem Neked.
Aztán eszembe jutott, hogy az email-eknél a múlt soha nem változik. Így szerintem dőreség napi rendszerességgel teljes backup-ot készíteni pont az email-ekről (de fixme). Pont ilyen esetben rendkívül előnyös az inkrementális mentés.
Nekem az az érzésem, hogy a megrendelők gombokért szeretnének sokat, ugyanakkor az infrások meg szeretik túlhájpolni kicsit a feladat valós bonyolultságát. Meg azt is bírom, amikor olyan összegeket kiszámláznak lassú bérelt vonalakért, amiknél egy komolyabb consumer kapcsolat egy nagyságrenddel gyorsabb. Lehet itt vitatkozni a rendelkezésre állásról, de akkor inkább veszek a consumerből kettőt, két külön szolgáltatótól.
Az adatok valós értékét meg szerintem sokszor túlbecsülik. Valóban vannak adatbázisok, amiknek az elvesztése közvetlenül leálláshoz vezet, de lófasz se történne, ha mondjuk egy heti email odaveszne. Ahol igen, ott szerintem más baj is van.
Szerintem ha 2021-ben luxus egy néhány gigás email fiók per user, az elég gáz.
Az emaileket bazinehéz menteni. Mivel dinamikusan változik minden fiók tartalma, ezért a snapshot jellegű pillanatkép nem az igazi. Ha a bejövő és kimenő emaileket archiválod, akkor ott megint egy halom probléma lesz. Minden esetre mondjuk megegyezés születik, hogy napi snapshot készül és mindez inkrementálisan (mondjuk rdiff-backup -pal, ami rsync alapú és egészen kezelhető a végeredmény). Itt egy idő után a file-ok darabszáma lesz a szűk keresztmetszet, az nagyon meg tudja nyújtani a backup futásának idejét. Mellesleg az sem ártana, hogy ha a backup nem egy helyre készülne.
Ha esetleg on-premises Exchange-et mentenének, miután felköhögték a kevésbé kellemes licenszdíjat, akkor jön szintén a használható backup szoftver licenszdíja és helyigénye.
Csak azt tudom mondani, mint korábban, hogy ugyan technológiában vagy kivitelezésben egyik sem ördöngősség, de jellemzően elsápadnak a megrendelők a költségvonzattól. Az igények az egekben, de erőforrás/pénz már nincs rá. Ez pedig sajnos igen sokunkba beégett már és ezért jön ez az erősen visszafogott hozzáállás. Különös tekintettel azokra az esetekre, amikor a féligmeddig megoldást végigvertek az ájtin (akik csak porszívózzák a pénzt és pláne akadékoskodnak, ahogy most énis), de amikor összedől a történet, akkor beindul a vérszívás, hogy ez elfogadhatatlan és ennyiannyi milliót bukott a cég (természetesen már megint), azon hogy tökörészik a mélyentisztelt ájti... Sajnos nagyon kevés hely van, ahol a hozzáállás normális vagy esetleg jónak mondható és értik, hogy ha valaki aszondja hogy X, akkor az nem Z/Y, hanem X és esetleg ért a dolgához (sőt van akár a konkrét témában sokéves tapasztalata).
Senki sem a néhány gigás, hanem az 50-100G-s fiókigényektől dobja a hátast, mondjuk egy minimum 25-50-es fiókszámnál, mert ahogy fentebb írtam, a ráfordítási oldallal ezt nemnagyon szeretik követni. Lásd aki egy tartalék diszket sem enged megvetetni...
Ahol diszket nem engednek megvenni ott ezt írásba kell kérni, kinyomtatni, és aláíratni a vezetővel.
Legyen valami amikor beüt a baj; ekkora szűkseggűségnél nyugodtan lehet ebédkor pörgetni a linkedint. Olyan mint amikor a takarítónak nem vesznek felmosószert, mert erősebben sikálva ugyanúgy lejön a kosz a padlóról.
Azért az ilyet, csak hírből ismerem. Az ilyen belső lelkivilágúak nem jutnak el az Ügyfél státuszig vagy roppant rövid életűek. :)
VM szintű mentéssel nagyon hatékonyan lehet menteni: mindegy, hány fájl van. Inkrementálisan is.
Azért egy Veeam is elég jól elmazsolázik több VM-men, még ha csak néhány 100G a nagyságrend, de az biztos, hogy a change block track miatt simán gyorsabb lehet.
Szerencsére ahol egy VM és hozzá a mentés felmerül, akár az ingyenes Veeam és valamilyen NAS opcióval, ott jó eséllyel megérti, hogy nem lesz 50x 1TB-os emailfiók csak úgy. :)
Az a kérdés ötlött fel bennem ezt olvasva, hogy ha btrfs-en ez fájlrendszer szinten deduplikálva lett és ugyan megvan a 11 fájl a Maildirekben, de csak 1-szer foglal blokkot a lemezen, akkor nincs valami olyan backup megoldás ami ezt az információt felhasználja és nem írja ki a backupba 11-szer ugyanazt az adatot?
Ahogy nézem az rsync manual nem szól reflinkről, szóval felteszem, hogy nem tud ilyesmit.
Vagy az lenne a megoldás, hogy az éles btrfs-ről rsync átmásol mindent a backupra, a kiscicás videót 11-szer, és aztán majd az offline dedup idővel felszabadít 10 cicás videónyi helyet (vagy 11-et, ha egy korábbi backupban már megvolt ugyanez)?
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Btrfs-en és zfs-en ehhez nem kell nagy varázslat, snapshot->send/receive egy másik btrfs/zfs rendszeren. Mondjuk szalagos arhíválás esetére nem tudok ilyenről.
Minden normális mentőrendszer tud inline deduplicationt (FS-től függetlenül) + vannak storage-ok is, amik tudnak ilyet, alapból backup/archive célra lettek kifejlesztve (pl. Data Domain).
en ott latom a problemat ha a ceges email cimet hasznalja magan celra es ott tortennek ezek.
ha a ceges email cimet csak ceges levelezesre hasznalja akkor ilyen nincs es kvota sem szukseges.
ha fogy a hely boviteni kell.
masik lehetoseg hogy iktatorendszert kell hasznalni, a fontos leveleket kezzel (nem automatizaltan mindent) bele kell huzni igy megmaradnak, ha kell lehet beallitani lejaratot.
a nem fontos levelekre lehet lazabb policyt alkalmazni
neked aztan fura humorod van...
Tény, hogy a magán levelezés kiiktatása segíthet, de nem egyedi eset, hogy kollégák emailben küldenek egymásnak olyan anyagot, ami a fájlszerveren is megtalálható és címzettek által elérhető. Akár jó nagy PDF-eket. Gondolom így egyszerűbb, mint elérési utat küldeni.
A bas64 sem éppen a tárhely takarékosságot szolgálja, bár erre nyilván lehetnek technológiák (tömörítés, deduplikáció).
ennek akkor van letjogosultsaga ha a fajl pillanatnyi allapotat akarjak atkuldeni, mert esetleg a fajlszerveren modosulhat
ha mindig az utolso allapotat kellene nezni akkor meg karos is, nade erre valo a virgacs :)
neked aztan fura humorod van...
Én azért úgy tapasztalatom, hogy üzleti felhasználók is tudnak "verziózni". Ráadásul a PDF-ek esetén ritkább az, ami módosul, mint ami nem (valóban, a törlés is egy változás, főleg ha létrehozás és törlés két mentés között történik).
mailbox:
immutable version repository
to do list
?
Erre valo az olyan storage ahol automatikus a verziozas. Ne emailben verziozzunk meg lebegtessunk cegen belul elavult verzioju fileokat...
+1
https://miro.medium.com/max/1200/1*pMk3h0dIYMb_I1iJCjriPQ.jpeg
Sajnos az IT szolgáltatástervezésből legtöbbször kimarad, hogy megkérdezzék a usert, mivel telik egy napja a melóban. :) Utólag meg kár csodálkozni, hogy a szuper secure enterprise IT miért van tele (gyakran kívülről hozott) félmegoldással, mint pl. az emailben csatolmány küldözgetés. Nemcsak a csatolmányok ilyenek.
Nemrég láttam olyat, hogy az IT nem engedett meghívni guest usereket (tanácsadók, alvállalkozók, stb.) a céges Teamsbe, ezért a csapat csinált magának Slacket, és azon ment az üzleti beszélgetés. Mindenki örült, az IT szerint secure maradt a rendszer, mert holmi alvállalkozók nem látják a céges fájlokat, a csapat meg tudott dolgozni nyugodtan a beszállítókkal.
Mi is így szoktuk: amikor akadályozva van a munkánk, jön a saját erőforrás.
Nem egyszer a saját webszerveremen osztottam fájlokat külföldi kollégának, mert nem volt egy nyüves mappa, amihez mindketten hozzáfértünk volna úgy, hogy én írni is tudom.
Az extenzív ho azért sokat javított a helyzeten. Lett rendes vpn, rendes routing, saját jitsi szerver (jó olyanokkal, akikkel nem megy a webex).
Ahol ehhez HO kellett, az very siralmas...
Mikor még a mail alám tartozott akkor csináltam azt hogy szoftkvóta volt, mindenki annyit levelezett, amennyit csak akart, de ha valaki havi >2g levelet generált, akkor odamentünk megkérdezni hogy miért, és kell-e. A sales hálás volt hogy pillanat alatt tudta mondani az ügyfélnek hogy egy D6HWK-1234-KABOOM kell neki, amikor ő csak annyit tudott hogy "má' megin elfogyott az ami a múltkor".
"hogy összedobunk nekik egy vinyóra" - ami rögtön nem egy, hanem legalább kettő (RAID), és ha netán nem pécébe dugott kommersz, hanem storage-ba rakandó cucc, akkor az ár is ennek megfelelően khm. magasabb, plusz a mentési tárhely (szalag) méretében is "lépcsők" vannak, bónuszként a mentési időablak sem végtelen... Messzire vezet egy ilyen "veszünk egy diszket..." dolog.
A lényegen nem változtat. Baromi kis költség a cég szempontjából, főleg ha nevetséges párszáz megákkal meg gigabájtokkal dobálózunk per júzer. Nem is értem ezt a kicsinyeskedést a 21. században. Melegvízre meg takarításra több megy el.
Igen, viszont amikor a menedzsmentnek vagy megrendelőnek összeírod, hogy ehhez mennyi plusz tárgyi és munkaóra szükségeltetik, akkor egyből átmennek szarrágásba.
Milyen munkaóra? Berakni a diszkeket?
A backup azért automatizáltan megy. Merem remélni legalábbis.
Más kérdés a pofátlan árképzés, illetve hogy egyes IT szerződésekben az árszabás kimondottan pénzkimentési alapon történik.
Nekem ezzel az egésszel a kicsinyeskedés a bajom. Jóval több adatot tárolunk (tároltatunk) pár TB-nyi email-nél.
A papíros archívumokat kellene inkább teljesen megszüntetni. Azoknak a fenntartása sokkal drágább.
Természetesen. Viszont az a backup, amelyik nincs letesztelve, az nem backup.
Igen, el se hinnéd mekkora szarrágás megy (milliárdos forgalmú) ügyfelek részéről az IT felé, képesek 2 óra kiszámlázása miatt egy hónapig rágódni, hogy kell-e vagy nem!
Nálunk csak a rohadt nagy ,,pazarlást" látom.
Érteni én sem értem, de egyre inkább elfogadom, hogy ez olyan alapvető dolog, mint mondjuk az anyagmegmaradás. (Mesélték, hogy amikor az egyik ügyfél rendszere bedőlt, és ment a tűzoltás, az ügyfél egy ponton elkezdte követelni, hogy állítsák vissza az adatokat az utolsó mentésből. Kiderült, hogy az ügyfél a szokásos gyakorlattól eltérően kifejezetten úgy kötötte meg a szerződést, hogy nem kért adatmentést... "Nincs pénz lóvéra", "semmi sem elég olcsó" stb.)
Legdurvább esetem: Milliárdos éves forgalmú cég. A merevlemezek már a végüket járták (S.M.A.R.T már kb mindenben rossz volt), szóltam (kb ezredjére), hogy már tényleg cserélni kell, utolsó utáni pillanatban vagyunk, csak az ima tartja életben. Nem, nincs rá pénz (2 hdd-re). 2 nap múlva meghalt a lemez. A tulaj szó szerint sírt, hogy oldjuk meg a problémát, kerül amibe kerül, mert tönkremegy a cég az adatok nélkül. Megoldottuk, több mint 2 millába került, a hdd csere 50ezer Ft-os költségével szembe.
Nálunk azért ezt szolgáltatás-szinten nyújtják. A szolgáltató feladata az is, hogy jó legyen a diszk.
Nyilvánvalóan, ha valaki ilyen szolgáltatást rendel meg, akkor az így működik, ahogy mondod, de ha nem, akkor meg nem így...
Gondolom ennek az árazása is más azért.
Természetesen, mint ahogy a költségvonzata sem ugyanannyi. Egyébként a szimpla üzemeltetéssel se lett volna gond, ha hajlandó lett volna elfogadni a beszerzési ajánlásokat a részünkről.
Őszintén szólva mi ezeket messziről kerüljük. Lefektetjük az alapokat, hidegtartalék a kopóalkatrészekből vagy valami erős (NBD szerű) gari, mert ez nem játék. Se neki, se nekünk. Vannak próbálkozások, hogy a 8000 éves NAS-nak (SMB1 only) jó lenne valami "jó kis feladat", de valszin már a nézésemből sejtik, hogy nem volt jó ötlet a kérdés. :) Sajnos nagyon sokan nálam/nálunk találkoznak a valósággal, meg hogy bazira oda kell figyelni, mert rommá üzemeltetheted a dolgokat, hogy ha csapatnak összevissza.
"a 8000 éves NAS-nak (SMB1 only) jó lenne valami "jó kis feladat"" - öööö... Van olyan szék, aminek törött a lába? Na az alá, hogy ne billegjen, tökéletes lesz :-)
Azt szoktam mondani, hogy ez már rég nem olyan, mint a dédapánk kalapácsa, amit esetleg könnyen és gyorsan fel lehet "újítani", ha kell... :-) Azt látják, hogy "dehát eccer kifizettük", pláne ha valami 100k feletti tétel, akkor annak a világvége+1 napig üzemelnie kellene lehetőleg.
annyi eszetek remelem volt hogy mikor lattatok milyen allapotban van a disk megis csinaltatok mentest es az abbol valo visszaallitas kerult ennyibe :)
neked aztan fura humorod van...
ez üzleti titok! :-D
Kis költség...? Láttam 1TB-os bővítésre milliós(!) ajánlatot - storage-ban kellett bővülni, plusz polc, és abba n darab diszk - mert "csak egyet" nem lehet belerakni.
Mentés dettó: nem mindegy, hogy plusz tárterület mentése/archiválása elfér-e az aktuális szalagmennyiségen, vagy plusz kazettát kell napi mentésbe, illetve havi archiválásba beforgatni.
Az az igazi, amikor az árképzésben megjelenik a jó diszk, valójában meg megy bele a desktop grade.
Szalagra mennyire jellemző archiválni még?
A szalag elsősorban offline/offsite archiválásra használatos - költséghatékonyan más módon nem nagyon tudod megcsinálni ugyanilyen szintű el- és leválasztással. (Lehetne diszkekre is archiválni, de az több szempontból érzékenyebb eszköz).
Azt tudom, hogy mire jó.
Arra vagyok kíváncsi, hogy mennyire elterjedt még.
Ahol offline/offsite archiválás elvárt, ott nem igazán van rá egyéb költséghatékony és biztonságos megoldás. Láttam már merevlemezes archiválást is - szerintem lehet az _is_ jó irány, de ilyenből láttam kevesebbet. Még.
Nagyon rég láttam már szalagos mentést. Bár ennek inkább az az oka, hogy messze kerültem a ,,körforgástól".
Milyen szalagok vannak használatban manapság?
https://en.wikipedia.org/wiki/Linear_Tape-Open
Köszi
azon kívűl, hogy az LTO-ra van magazin (egyszerűbb cserélni) - mivel jobb, mint vinyóra menteni?
Gyanítom a tömörítés software alapú, tehát kb olyan mintha egy bzip-en át hajtaná az ember a vinyóra a mentést, v rosszul gondolom?
(vagy a vezérlő kártyába van integrálva a tömörítést végző CPU)
Van egyébként olyan árfekvésű tape, amit soho környezetben érdemes lehet fontolóra venni?
Nem a cég mérete, hanem a mentendő/archiválandó adatok mennyisége, elvárt megőrzési idő (ez általában többféle, van, amit 1-2 évig, van amit 5 vagy 10 évig, és lehet olyan is akár, amit "lejárat nélkül" kell őrizni...), a mentések/archiv adatok tárolására vonatkozó céges és hatósági elvárások azok, amiket mérlegelni kell. Van, ahol egy megfelelően nagy kapacitású LTO a jobb megoldás, van, ahol merevlemez, és van, ahol mondjuk egyszer írható optikai tároló.
Papírforma szerint hosszútávú a tárolás (megfelelő magnóról nem árt gondoskodni), ezenkívül egyesek csak ebben látják például a zsaroló vírusok elleni védelmet (azt el kell ismerni, hogy kivett szalagot nehéz megfertőzni, de egyéb faktorok miatt - például költség - nem feltétlenül optimális a 100%-ra menni).
Mentés vagy archiválás? A mentés teljesen jól elvan diszken/VTL-en, viszont az offline+offsite feltételeknek kazettával lehet a legegyszerűbben eleget tenni: kivesz, elvisz, páncélszekrénybe berak. Diszket is ki lehet venni, azonban nem minden diszkfiók csatlakozója szereti mondjuk napi/heti gyakorisággal a diszkcserét.
Volt diszkes archiváláshoz szerencsém: ott 4 diszkes tükör volt, abból kettő lett minden hónapban kiszedve/cserélve, és megfelelő dobozban elrakva két külön értéktárban. Gyors volt, a visszaállításhoz sem kellett csillió óra - ellenben a mentett adatok eredetiságe nem volt garantálható (írható média ugye...) - ahol meg szalagos archiválás van, és komolyan veszik, ott egyszer írható kazettákkal operálnak.
Nekem 98-ban az egyik kollégám nagyon nyomta, hogy szalagos mentés helyett legyen merevlemezes, mert már akkor a szalagos meghajtó + a szükséges mennyiségű kazetta árából lehetett annyi harddisket venni, hogy a teljes mentési mennyiséget több példányban le lehetett menteni, gyorsabb is volt, megbízhatónak is megbízható, mivel több példányban is megvolt minden, ezért meg lehetett valósítani több offsite helyet is, stb.
Nem hiszem, hogy azóta megváltozott volna ez a helyzet, szóval ha az elmúlt több, mint 20 év alatt nem terjedt el, akkor talán nem is fog.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Rémlik valami kartridge-os diszkes mentőeszköz a régmúltból, de való igaz, a legtöbb helyen nem diszkeket cserélgetnek, hanem kazettákat - akár komplett szobányi térben elrakva az xcsillió darabot, és robotizálva a pakolászást.
Ami diszkes vonalon van, az jellemzően VTL, azaz a mentőszoftver felé kazettákat mutat, de valójában diszken tárolja az adatokat - megfelelő kialakítás esetén offline/offsite kritáriumnak is meg lehet vele felelni. A diszkre kiírjuk, kivesszük a diszket és eltesszük a páncélba is jó _lehet_, de ahhoz kifejezetten egyedi megoldásokat ismerek csak.
A tárhely korlátnak van egy másik oka is. Ha kellemetlenül szűkös a kvóta, kénytelen vagy törölni nagy csatolmányokkal rendelkező leveleket, mert hisz anélkül n*10.000 levél elférne a mailboxban. Így valamelyest tompítani tudod, hogy érzékeny adatokat tartalmazó szerződésekkel legyen teli a mailbox, amit ha feltörnek, van baj.
Ha ezt a cég learchiválja - ahogy te is mondod - ugyanúgy foglalja a helyet, máshol. Jellemzően LAN-on belül, ahol kisebb a kockázat.
Pont a csatolmányok azok, amikre később szükség lehet.
Másrészt nálunk nem a törlést ösztönözték, hanem hogy rakjam át az Archive mappába. Ami ugyanúgy tárolva van és gondolom backupolva is. Csak pl. a telefonomról már nem érem el és PC-ről is nehézkesebb, nehezebben is kereshető.
Volt olyan munkahelyem, ahol nem volt szabad IMAP-et használni, csak POP3-on letölteni az email-eket. Pont ilyen dumával, amit mondasz: hogy ne legyen ott, ha feltörik a rendszert.
Pusztulat. Ilyen alapon papíron is mehetne az egész. User szempontból (számomra) ezek nonszenszek.
És erre egy jó irány, hogy nem az email-ben megy a titkos szerződés át egy csomó kézen, hanem a másik oldal kap egy linket, ahol megfelelő azonosítás után megnézheti a titkot.
Vagy lehetne persze titkosítani is a leveleket, és a mailbox feltörése után nem nincs nagy baj, ha a hacker nem szerezte meg valahogy a GPG/PGP kulcsot és a hozzá tartozó jelszót is. De ahogy nézem, a titkosítás nem lett divat.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Nálunk divat a titkosítás. De nem GPG-vel, hanem saját, integrált megoldással. Nyilván csak a saját ekoszisztémán belül működik.
PGP is és S/MIME is kiválóan integrálva használható pl. Outlookból. Feltételezem más levelező kliensből is, de Outlook-on kívül (GPG-t) csak KMail-lel és mutt-tal használtam, azok meg nem annyira elterjedt kliensek.
De egyébként mindegy is, hogy mivel titkosítasz, mert legalább van valami. Hány másik céget láttál, ahol divat volt a titkosítás?
Számomra egy kicsit csalódás, hogy ilyen technológiák, mint PGP nem terjedtek el az elmúlt mondjuk 25 évben szinte egyáltalán.
Volt már, hogy PGP-vel titkosított levelet küldtem valakinek, talán 3 esetben 3 különböző embernek `96 óta (vagyis általában titkosítatlanul leveleztünk, de volt egy darab levél, amit titkosítva küldtem, mert olyan információk voltak benne, amit meg akartunk védeni). És volt egy ember, akivel minden levelezés titkosítva ment. Ráadásul ez magánlevelezés volt, szóval még csak nem is a titkos tartalom miatt. Emellett talán 5-10 alkalommal kaptam S/Mime titkosított emailt cégen belül, feltételezem, hogy a küldő minden levelét titkosította, de a cégnél egyébként senki más nem küldött így emilt.
Szomorú azt látni, hogy nem használják ezt a technológiát, aztán meg megy a para, hogy mi lesz, ha feltörik a mailboxot.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
PGP, Outlook... Cirka 20 éve volt szerencsém ilyet bevezetni egy cégnél adott partnerrel történő kapcsolattartásra, illetve adatcserére. Sok-sok screenshot volt a doksiban, az igaz, de a nem IT-s vénájú felhasználóknak is sikerült megtanulni a használatát :)
Számomra is. Ketten voltak, akikkel rendszeresen GPG-vel leveleztem. Volt akkoriban a gmail-hez egy gpg plugin, az ellenoldalak ezt használták. A google mintha mindent megtett volna, hogy kibabráljon a fejlesztőkkel, állandóan broken lett.
Szerettem, mert nem tudott más beleolvasni ha pl. közös gépen bejelentkezve maradt az illető (volt rá példa), vagy bármilyen más módon is exposed lehet a mailbox.
Például húgomnak a levelezését többször feltörték. Volt, hogy megváltoztatták a jelszót és be sem tudott lépni a saját mailboxába.
Számomra a magánlevelezés biztonsága fontosabb. Nem értem, miért van sokakban ez a ,,cég előbbre való" kultúra. Az embereket kellene jobban védeni.
Szerintem az emberek többségében nem merül fel ez a lehetőség, hogy elolvashatják a leveleiket és hogy ez adott esetben milyen kellemetlen lehet. Külön erőfeszítést meg nem tesznek, hogy megértsék a PGP/GPG lényegét és működését.
Ugye onnan indult ez a thread, hogy valakik egy cégnél féltek, hogy a céges mailboxhoz illetéktelen hozzáfér és kiderülnek a titkok.
A másik három, akikkel leveleztem, ott valóban üzleti titkok mentek a levélben.
Ebben az esetben meg csak olyanok, mint "hé, hánykor menjünk ebédelni ma?", szóval nem a tartalma miatt ment a titkosítás.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Thread-től függetlenül, általában érzem elhibázottnak azt a gondolkodást, hogy a cég sokkal fontosabb a parasztnál. Miért? Szerintem pont fordítva kellene legyen.
A zsarolók is többnyire a privát viselt dolgaival szokták zsarolni az igazgató urat, nem a tavalyi könyvelési adatokkal.
A zsaroló scam levelekben sem azt kéne írni, hogy "felvételünk van róla, hogy kivered", hanem azt, hogy megvan a kis fekete notesz másolata. :D
Én nem azt mondom, hogy a cég fontosabb. Szerintem a céges és magánlevelezést is jó lenne titkosítani.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Egyetértek. Jó lenne.
Arra reflektáltam, hogy sok beszélgetésben a céges témák valami nagyságrendekkel fontosabbként jelennek meg, mint a magán dolgok. Pedig szerintem pont fordítva van.
Nem vagyok benne biztos, hogy pont fordítva van, nekem például nagyon kevés olyan magánlevelezésem van, aminek nyilvánosságra kerülésétől kétségbe esnék, bárki bármilyen módon profitálni tudna belőle az én káromra, vagy csak simán a saját hasznára (ha lenne ilyen, az már talán üzleti kategória lenne vagy celeb lennék, ami megint üzlet kategória).
Szerintem több dolog van ennek a hátterében:
A könyvelés nagyon kényes üzleti adat (és még sok minden más), az igazgató nem feltétlenül korrumpálható, pláne emaillel (például kurvázáshoz nem kell emailt írni).
Ami negligálva van a magán szférában, az a biztonsági mentés. Friss eset, hogy valakinek minden privát anyagát (beleértve gyerekről készült képeket) letitkosította egy vírus, de gyanítom, hogy ez nem egyedi.
Ha tárhelyet kér, akkor tárhelyet adsz neki, és kiszámlázod.
Hashes bűvészkedésnél nem tudod bizonyítani hogy mi az amit elküldtél, csak azt hogy elküldtél valami azzal a hash-el.
Emellett azt csak "szakértő" tudja üzemeltetni, ő maga nem tudja screenshotolni, újraküldeni a levelet (puha) bizonyítékként.
Természetesen "hard" bizonyítéknak egy archiváló rendszer lenne a jó, de az szintén nagyon nehéz felhasználói oldalról.
Érdelne, hogy milyen entitás felé bizonyító erejű egy email megléte a kimenő mappában? :D
De tovább megyek, attól hogy tőled hitelt érdemlően kiment, SEMMI nem garantálja, hogy a címzett meg is kapta...
(azt pedig hogy 'kiment' kizárólag az SMTP szerver logjaival lehetne hitelt érdemlően alátámasztani)
Vagy is ez olyan mint a Postán az ajánlott küldemény kézbesítése, hogy akkor is kézbesítettnek számít, ha valójában senki soha nem vette át?
csak én érzem úgy hogy (ismét) egy jogi problémát akar valaki (nem feltétlenül a topiknyitó) technikai megoldásokkal 'orvosolni'?
zrubi.hu
+1
Csak a párszáz byte-os tértivevényeket (szerver érkeztetés, user elolvasás) érdemes elrakni, de annak meg nem kell sok tárhely.
Az érkeztetéssel is csak azt tudja elérni, hogy ő tényleg küldött abban az időpontban valamit és innentől a túloldal lesz kedves igazolni a szerver LOG-ból hogy nem, vagy ha igen akkor másra adott választ.
Az "elküldött" email tartalom utólag is könnyen hamisítható, így bizonyító ereje annak nincs.
Kivéve ha digitálisan aláírt rendszeren ment át, de ebben a témában még csak kevés példa van (pl. ügyfélkapu).
Volt már hogy ilyen kellett csinálni, annak ellenére hogy maga az SMTP protokoll erre nem alkalmas.
(megjegyzem, ez sem kis meló hogy ezt a tényt az érintett manágerek/politikusok/jogászok felfogják)
Ilyenkor, ha télyneg fontos hogy elment-e egy adott levél, a következő megoldást alkalmaztuk:
- mindkét félnek volt saját üzemeltetésű SMTP szervere.
- a két fél egy 'trusted SMTP' csatornát épített ki egymás között (TLS + direct mail routing)
Ha kérdéses volt egy-egy levél sorsa, azt mindkét fél meg tudta nézni a saját szerveri logjában. Esetleges vita esetén a kettőt össze is lehetett vetni.
Ez egyértelműen megoldotta a problémát, nem kellett a levelező rendszerben tárolni az elküldött szarokat.
(máshol amúgy is kellett, mert számlákról volt szó)
Persze, ez a mai 'felhős világban' már nem igazán kivitelezhető - de legalábbis egy (vagy több) harmadik felet is be kell vonni a játékba.
zrubi.hu
Anno nekem is volt ilyen projektem - ott addig lehetett elmenni a bizonyítással, hogy a küldőtől az xyz szerver átvette az adott levelet - de ennyi elég is volt, később az "el is olvasta" is megvalósult úgy, hogy a levélben csak egy egyedileg generált link ment ki, és megfelelő auth után letölthető/megtekinthető volt a dokumentum - a központi loggyűjtőben meg össze lehetett futtatni a levél kiküldve eseményt a dokumentum letöltve eseménnyel.
Végeredményben azért az a tanulság szerintem, hogy ilyen esetekre, amikor a bizonyíthatóság ennyire kritikus, nem megfelelő metódus az emailben való elküldés.
Legfrissebb példa a helyi önkormányzattól. (59. oldal 3.1.1) Így szerződik a közszféra.
Fentebb a rangsorban megírják, lentebb meg kell valósítani, hogy követhető legyen. [off]Ez már a transzparens ellenzék, így legalább látom, hogy miket írnak bele, de bár ne látnám (nem a 3.1.1 a fő probléma), pontosabban bár ne kötötték volna meg így. (2.1, 5.3.3.2, 6.11) Nehéz eldönteni, hogy nemtörődömség/inkompetencia vagy szándékos, hogy legy egy kis filmek/sorozatok topik relevancia is, a Ian Buckells dilemma[/off]
Ebből a történetből az hiányzik számomra, hogy mindkét fél a saját logjából generáláskor egy elektronikusan aláírt példányt átküld a másik fél (vagy egy pártatlan harmadik fél) felé.
Mert az OK, hogy ha a két log egyezik, akkor egyértelmű, de ha le akarom tagadni, hogy megkaptam a levelet, akkor szólok az IT-nak, hogy töröljék azt a bejegyzést a log fájlból (vagy a másik oldalon szólok nekik, hogy írják bele), és akkor megint csak az lesz, hogy az egyik oldal ezt mondja (és mutatja a logokat), a másik oldal meg azt mondja (és mutatja a logokat).
Érdekességképp mondom, hogy nálunk úgy volt egy helyen megoldva az, hogy a logot senki ne módosíthassa (nem email, hanem céges beléptető rendszer), hogy volt egy mátrixnyomtató kötve a szerverre, és amikor érdekes log bejegyzés íródott, az a sor ment a nyomtatóra is azonnal. Be volt fűzve a kb. végtelen leporello, aztán ha valami vita volt, és a log megnézése után még mindig felmerült valami suskus, akkor lehetett böngészni, hogy mit nyomtatott ki akkor a gép.
Azóta eltelt 24 év, most már inkább remote logot és / vagy digitális aláírást javasolnék.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Ahol olyan az igény, ott a loggyűjtés láncolt hash vagy más módon ellenőrizve vagyon, hogy került-e bele plusz sor, vagy hiányzik-e belőle valami.
mondjuk ha a konyvelo partnere visszairna hogy a "2020. evi beszamolot megkaptam koszonom" akkor eleg lenne azt eltenni.
vagy ha annyira fontos hely mint pl. a nav, a magyarorszag.hu tarhelyre feltoltott dokumentumokrol jon egy atveteli ertesito benne hash-al
neked aztan fura humorod van...
Imádom, amikor elküldök egy e-mailt, benne pármegányi csatolmánnyal, és 5 perc múlva jön a válaszüzenet: Köszönöm. És az egész eredeti levél, csatolmányokkal együtt. Ennek advanced verziója, amikor van 5-6 címzettem, és a köszönetbe beleveszik az összes címzettet.
(Egyáltalán milyen levelezőkliens pakolja a válaszlevélbe a csatolmányokat?!)
Én meg azt imádom, amikor a többedik fordulóban kerülök bele a diszkusszióba, és a korábbi csatolmányokat már mind automatán törölte a rendszer... Vagy amikor vissza kell keresni az eredeti elvelet, mert csak abban van meg a csatolmány.
Ezeket oldják már meg low level, ne a júzernek kelljen szívni miatta.
thunderbirdnel ugy van hogy tovabbitaskor benne van a csatolmany valaszkor nincs. annak megfeleloen kell hasznalnia a felhasznalonak, hogy mi a szandeka.
neked aztan fura humorod van...
Nekünk is ez a default. Plusz van olyan válaszlehetőség a kis nyílra kattintva, hogy válasz mellékletekkel.
milyen kis nyilra kattintva? vagy nem thunderbirdben van ez?
neked aztan fura humorod van...
Ez nem Thunderbird-ben van. Nálunk nem IMAP alapú az email, hanem egy kész megoldást vásároltunk meg, ami egy picit beyond-email. Ha úgy tetszik, a border-en van email gateway.
igy ertem, mert nem talaltam es neha azert jol jonne a thunderbirdben is :)
neked aztan fura humorod van...
Az alap problémára nincs megoldási javaslatom, ami most van az nem bizonyíték, ha hash lenne az se lenne bizonyíték, szóval kb. mindegy is.
Csak azt akartam írni, hogy az utóbbi időben sok helyről úgy kaptam dokumentumokat, hogy valami online rendszerbe feltöltötték és én egy linket kaptam. Az online rendszer pedig rögzítette, hogy ki töltötte fel és mikor a cuccot.
Amennyiben az online rendszer üzemeltetőiben megbízik valaki, akkor ez lehet bizonyíték + nem kell helyben tárolni a nagy méretű dokumentumot.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Így van, ahogy többen is írjátok, ez nem bizonyíték.
Ha bizonyítani nem is, meggyőzni azért lehet az elővett email-ekkel. És ez sokszor elég. A morzsákból gyakran kiderül, valószínűleg ki a hunyó és hol kell tovább kapargatni.
A bírói gyakorlat is csak a nagyon komoly ügyekben vár el kétséget kizáró bizonyítékot (FIXME). A belső céges ügyekben pedig tökéletesen elég szokott lenni.
Mondjuk egy dropbox(szerű) tárhelyre menti Mancika a csatolmányt, és csak a linket küldi? Azon gondolom látszik, hogy mikor lett feltöltve (és nem tudod manipulálni), nem terheled a saját és a fogadó tárhelyét sem, és időnként (havonta? félévente?) kipucolod a régieket. Win-win-win. A mega ad 50 GB-t ingyen, az már csak elég...
Nálunk a cégnél központilag tiltják a fájlcserélők használatát (helyesen). Én még a privát dolgaimat se másolnám fel ilyen szolgáltatókhoz. Akkor már inkább saját felhő (nextcloud) a cégnél (és otthon is).
Azért ez cégtől is függ nagyon.
Dolgoztam olyan céggel, ahol Google suite (ha jól tudom a nevét) volt, és a Google Drive-on tárolták a dolgokat. Sok másik cég (a jelenlegi is pl.) Microsoft365-öt használ, az összes levelezés is a felhőben van, de emellett OneDrive és felhős Sharepoint van a dokumentumok megosztására.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
A levelezőrendszer logja (kiment a mail a levélazonosító alapján) nem elegendő?
Akkor Mancika törölhetné a kimenő levelében a csatolmányt, de azt mondja a csatolmány neve, tartalma is fontos, ezért megtartja.
Így a szerver log kevés. Ha csak nem tudok egyéb infót is belecsalni. Innen jött a név+hash irány.
rspamd-nek (ez egy spamszűrő megoldás) van medadata exporter modulja, ahhoz lehetne írni egy hashelős plugint.
https://rspamd.com/doc/modules/metadata_exporter.html
A postfix-ben az always_bcc vagy recipient_bcc_maps segítségével tudsz a levelekről egy extra címre másolatot küldeni.
Ha ezt a bcc címet alias-olod a címet valami saját scriptre, akkor azzal azt csinálsz, amit csak akarsz.
Ez nem is rossz ötlet, köszi! Vagy postfix oldalról vagy a scriptben feltételhez kötni, hogy ha csatolmány van, dolgozza fel és törölje a levelet.
Ez akár egy iktató rendszer része is lehet illetve a céges adatszivárogtatás ellenőrzésének egyik eleme.
Nem olvastam végig a topicot, elnézést ha volt már.
Nemrég volt hír, hogy egy könyvelőiroda a kimenő email-el akarta bizonyítani, hogy ő elküldte a számlát az ügyfélnek. A bíróságot nem igazán érdekelte és az ügyfélnek adott igazat, aki azt állította nem látta és senki sem szólt neki, hogy fizetni kell.
[update]
megtaláltam a cikket:
kizárólag az az e-mail minősül átvett levélnek, amit az adós vissza is igazolt, hogy megkapta
Énekes kérdés ez a bizonyítás. Ha jól tudom, javítsatok ki ha nem igaz (nem informatikus vagyok), akkor a szabvány se garantálja, hogy az elküldött levél megérkezik a címzettnek. Ebből kifolyólag, csak azt tudjuk mondani, hogy elküldtük a valamit, valahova. Azt nem bizonyítja, hogy a címzett meg is kapta. Hol akarom ezt a bizonyítást felhasználni? Hol tudom ezt a bizonyítást felhasználni? Ezen kell elgondolkodni és nem az informatikának, hanem a könyvelőnek, a jogásznak, cégvezetőnek.
Előttem is többen mondták, hogy nem érdemes, sőt nem szabadna pénzügyi vagy érzékeny adatokat tartalmazó dokumentumokat mailben küldeni. (információ biztonsági probléma, adatvédelmi probléma, GDPR, stb.) Ne felejtsük a papír alapú számlákat is legalább egy borítékba beletesszük, és nem egy levelező lapon küldjük el, mint amilyen az e-mail.
Magam szempontjából én azt tartanám elfogadhatónak, hogy a dokumentum feltöltve, akár a vállalat szerverére, akár küldő tárhelyre és mailben csak egy linket küldünk el, ahol megfelelő autentikáció után lehet csak megtekinteni az adatokat, dokumentumokat. (A kisebb tárhely rögtön megoldva a levelezésnél!!!) Az elküldés, bizonyítása még itt is problémás, nem megoldott, de annyi segítség van, hogy ha megnézte a dokumentumot (másik különálló log), akkor más nem egy adat van arra, hogy megkapott valamit, hanem kettő, ez már könnyíti a bizonyítást.
Plusz előny lehet még az is, hogy ha látjuk, hogy egy dokumentumot nem néztek meg, akkor akár figyelmeztetést is küldhetne a rendszer a a levél írójának, hogy nem olvasták el a küldött dokumentumot, ismételje meg. (igen, ezt le kell fejleszteni, de ha annyira szükséges a bizonyítás, akkor meg kell csinálni.)
Ez csak a technikai része a dolognak. Egy másik része, amit szintén nm az informatikának kell megoldani, hanem a jognak, hogy a szerződéseket úgy kell megírni, hogy abban az értesítések, illetve azok átvétele is meg legyen határozva
Ennél durvábbat is látott a világ: üf. adatok között kötelező volt az e-mail cím, a cég arra küldött mindenféle értesítést, kivonatot, etc. De senki nem ellenőrizte, hogy az adott e-mail cím az adott üf.-hez tartozik, ahhoz neki van hozzáférése, egyáltalán hogy létezik-e az adott postafiók... (Jó, a visszapattanó leveleket elvileg nézték, és utánajártak... Elvileg.)
Sőt mi több, most ez a legmodernebb Nemzethy Informathykai standard. Lásd vakcina-regisztráció. :)
Arra van mód, hogy SMTP kiszolgáló küldjön kézbesítési igazolást, ezt DKIM-mel aláírva már kicsit beljebb vagyunk. Nem tudom, ez bíróságon mennyire állja meg a helyét, de adott esetben az is több a nullánál, hogy adott levél elküldésre került, a címzett rendszere átvette. Ez ráadásul nem űrtechnológia.
5 dolcsi egy Microsoft 365 Business Basic Plan, 1 TB-os tárhellyel.
5 dolcsi 1Tb tárhely...én adok neked 1 dolcsiért is. Csak hozz még magaddal másik 500at akinek el tudom adni. (igen, ugyanazt az 1TB-ot) Nem aggódom, a 15Gbos gmailed se nagyon telik...