Cégetek levelezőrendszerében mail retention policy ....

Egyéb

nincs / levelek "örökre" megmaradnak.
67% (194 szavazat)
1 évig maradnak meg a levelek archiválás / törlés előtt.
3% (9 szavazat)
2 évig maradnak meg a levelek archiválás / törlés előtt.
1% (4 szavazat)
3 évig maradnak meg a levelek archiválás / törlés előtt.
1% (2 szavazat)
4 vagy több évig megmaradnak a levelek archiválás / törlés előtt.
1% (4 szavazat)
Egyéb, leírom.
3% (8 szavazat)
Csak az eredmény érdekel.
23% (67 szavazat)
Összes szavazat: 288

( BlinTux v | 2015. 05. 19., k – 13:42 )

Attól függ...
Ha nem olyan fontos akkor törlöm.
Ha kicsit fontos meghagyom.
Ha kicsit fontos volt valamikor de már nem, törlöm.
Ha többet nem találkozok vele, megmarad a gmail mélyebb bugyraiban.

( jassbg v | 2015. 05. 19., k – 14:10 )

Az 5. válasznak így nem sok értelme van.

------------------------------------------
No God, no peace. Know God, know peace!

( Takaya | 2015. 05. 19., k – 18:01 )

Az elmult 3 ev osszes emailje megvan, es nem is tervezik torolni oket. Jo dolog, ha neha vissza tudok keresni valamire amirol talan 1 eve volt szo.

--

"You can hide a semi truck in 300 lines of code"

( freeoli v | 2015. 05. 19., k – 15:20 )

Van egy régi sláger, a címe No limit, ajánlom és küldöm mindenkinek. Kivétel a levélméret.

( dejo v | 2015. 05. 19., k – 15:45 )

Nincs törlés. Amit a felhasználó nem töröl az idővel átkerül az archívba.
Az archiválás gyakorisága az illető leveleinek mennyiségétől függ. Van akinek 5 évig is elfér van akinek évente kell archiválni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( soproni v | 2015. 05. 19., k – 16:17 )

User látszólag tud törölni (saját fiókjából bármit), de igazából a szerveren megmarad minden levél.

( bri | 2015. 05. 19., k – 16:43 )

Inboxban 3 hónap, project folderben 6 hónap.

alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

( xea v | 2015. 05. 19., k – 16:47 )

A kedves Ugyfel szerzodesetol fugg, es ugyfelen belul is konfiguralunk 0-day retentiontol kezdve orokkevalosagig, az igenyeknek megfeleloen.

( dzsambo | 2015. 05. 19., k – 16:48 )

Nálunk 5 év és nincs archiválás.

( gemnon v | 2015. 05. 19., k – 16:56 )

Örökké, vagy legalábbis amíg nem telik (vagy hal le) a "jelenleg" 3TB-os RAID tömb, én a (2003 óta hízó) 11GB-os fiókkal csak kispályás vagyok :(.

( aga_et v | 2015. 05. 19., k – 23:58 )

Egyéb. Tárhelyfüggő. Megmaradhatna örökre is, de ha betelik törölni kell belőle. Bérelt olcsó felhő átka.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

A kérdés arra utalt, hogy a céges levelezőrendszeren meddig visszamenőleg vannak meg a levelek a törlés vagy archiválás előtt. A lehetőségekből egyértelmű szerintem ez.

Mondok egy példát:

Nálunk 1 évig visszamenőleg tárolódnak az e-mailek a mailszerver(ek)en. Az egy évnél régebbiek folyamatosan mennek át a mail archívumba. Így nem kell drága enterprise diszkeken pörgetni olyan adatokat, amik sosem kellenek, vagy csak rendkívül ritkán. Ezek egy más területre kerülnek, ott megőrződnek még X évig. Viszont az éles levelek csak 1 évig vannak meg a levelezőrendszeren.

--
trey @ gépház

Mivel a terméket forgalmazzuk, jó ha van egy élesben működő rendszer, amiről

a) van első kézből tapasztalat (bugok stb.)
b) tudok referenciát adni az eladások mellé (gyere el, nézd meg és döntsd el, hogy ez kell-e neked)

erre a legjobb a dogfooding.

Mellette persze vannak más okok is, de ezek a főbb okok.

--
trey @ gépház

pl. a legtobb mta-ban van valamilyen spamszuro megoldas, de ha korrekt modon akarod csinalni, akkor valoszinuleg egy masik (vendor) termeket is hasznalod a celra. A postfix iroja igy magyarazza, hogy miert nem patkolt bele o egy csili-vili antispam implementaciot:

"The more sophisticated content filtering software is not built into Postfix for good reasons: writing an MTA requires different skills than writing a SPAM or virus killer. Postfix encourages the use of external filters and standard protocols because this allows you to choose the best MTA and the best content inspection software for your purpose."

Hasonlo a helyzet az archivalassal is. Pl. a microsoft-nal biztos van olyan ember, akinel megvannak azok a different skill-ek, de nem veletlen, hogy az exchange-beli implementacio is (meg) csak karcolgatja a feature-t. Csak 1 nehezseg: az exchange szakitott a single instance storage elvvel, ami archivalas ugyben elegge buko. Nem tud mellekletet sem deduplikalni, igy hatekony mar biztos nem lesz (gondolom, ezert nyomatjak, hogy az olcsobb sata diszkek is jok lesznek ;-)). Ill. nem titkositja a diszkre kiirt leveleket, igy pl. egy olyan cegnel, ami a SoX hatalya ala esik, hasznalhatatlan a microsoft implementacioja.

Es ez csak par ok, ami alapjan jobban erheto, miert nem trivialis egy mail szerver + email archivum osszehazasitasa.

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Annyiban, hogy mindenféle limlommal nem szoktak ilyet összerakni.

Tudom, hogy a Microsoft szerint az Exchange már nyugodtan mehet SATA diszkre (persze, ott is meg van említve, hogy "Consider enterprise class SATA disks, which generally have better heat, vibration, and reliability characteristics."

Sok mindentől függ szerintem, hogy mi a megfelelő választás.

--
trey @ gépház

Nem önmagában az Exchange alá kell, hanem a felsoroltak alá. Az Exchange csak egy kis valami a kupac tetején, ami alá kell rendes cucc, hogy képes legyek menet közben áttenni másik node-ra, hogy menet közben képes legyek az egyik storage-ról áttenni a másikra, hogy megfelelő sebességgel fusson, hogy éjjel biztosan lefusson a mentés a backup window-ban stb.

Most ha azt nézed, hogy egy cégnek fel lehet egy vasra pakolni az egészet két desktop SATA HDD-re RAID1-ben, az is működik. De ahol nem remegő gyomorral akarnak éjjel aludni és nincs olyan személyzet, akinek semmi más dolga nincs, mint ezt tutujgatni, akkor azért kell alá rendes cucc.

--
trey @ gépház

Nem mondtam, hogy nem kell alá "rendes cucc", de szekvenciális írásra való diszkek elegendőek.
Jól értem, hogy azért vagy kénytelen nagyobb teljesítményű és ezáltal drágább diszkre tenni az Exchange-et, mert helyben nem tudod kielégíteni a különböző kategóriájú storage igényeket, így mindent inkább a legdrágábból szolgálsz ki?

"ha azt nézed, hogy egy cégnek fel lehet egy vasra pakolni az egészet két desktop SATA HDD-re RAID1-ben" -- nem nézek ilyet.

Üdv,
Marci

Nem, rosszul érted. Ha nem lenne ilyen infrastruktúra, akkor sem tennék halálfejes szolgáltatás alá SATA diszkre. Még ha személyesen a diszkgyártó vezérigazgatója is lenne az, aki mellette érvelne. Láttam én már karón varjút.

És nem feltétlen a teljesítmény, hanem inkább a megbízhatóság miatt (SATA vs. SAS). Egyébként egy kattintással tudnám menet közben SAS-ról áttenni SATA tárolóra az Exchange szerverünket úgy, hogy menet közben észre sem vennék (esetleg a teljesítménye lenne kisebb a storage migráció alatt), de nem hiszem, hogy én leszek az, aki ilyenekkel fog kísérletezni.

Másrészt, ahonnan indultunk, elég messze jutottunk. Ha jól értem, te valamiért a mailarchiválás ellen vagy. Vagy rosszul értem?

--
trey @ gépház

tan az exchange 2013-ban vezettek be bizonyos archivalasi funkciokat, ami kisebb panikot okozott a kereskedelmi email archivalo termekek gyartoi koreben. Ezert kulonfele 'felvilagosito' kampanyokat szerveztek a sajat letuk igazolasara, azt bizonygatva, hogy a microsoft megoldasa nem teljes erteku, es szukseg van 3rd party megoldasokra. Nyilvan a microsoft meg az ellenkezoje felol kampanyol...

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

"tan az exchange 2013-ban vezettek be bizonyos archivalasi funkciokat"

Kicsit konzervatív vagyok ilyen téren, a Microsoft új technológiáinak szoktam adni 2-3-4 évet, hogy érjenek. Sem szerverből, sem Exchange szerverből nem üzemeltetek legújabb verziót saját célra (néhány kivétellel). Annak idején Exchange 5.5-ről 2003-ra, 2003-ról 2010-re migráltam (swing migration).

A 2007-et pl. kihagytam és nagyon nem bántam meg. Lehet, hogy a 2013 is erre a sorsra jut.

--
trey @ gépház

"Kicsit konzervatív vagyok ilyen téren, a Microsoft új technológiáinak szoktam adni 2-3-4 évet, hogy érjenek. "

Mindenki maga választja meg, hogy hol helyezkedik el az adoption curve-ön. Ráadásul mindegyik stratégia érvényes lehet - attól függ, milyen üzleti stratégiához kapcsolódik.

Üdv,
Marci

15 év Exchange üzemeltetés után én valahogy nem hiszek abban, hogy ha kijön egy új verzió, akkor az admin (akár 3-4 korábbi generációval a háta mögött) elmegy egy gyorstalpaló MS Exchange tanfolyamra, akkor onnantól halálbiztosan fogja élesben alkalmazni az ott elhangzottakat, a migrálás tekintetében felelősen tud dönteni és az ügyféligényekre azonnal tud megfelelő választ adni. Lásd: a Microsoft egyszer úgy döntött, hogy elsorvasztja az Public Folder-eket a 2007-ben, aztán ügyfélnyomásra mégis engedett és továbbra is él a 2010-ben.

Aki 2003-ról az elején 2007-re váltott, az sokat szentségelt a PF-ek migrációja és/vagy kiváltása miatt. Aki kivárta a 2010-et, az gyakorlatilag probléma nélkül migrált menet közben, úgy, hogy abból a felhasználók semmit sem észleltek.

Természetesen most is üzemeltetek Exch 2013-at, ahol azt kérik, azt kapnak. Illetve, új rendszerek esetén nyilván azzal indulunk. Migrálás esetén azonban teljesen más a helyzet.

--
trey @ gépház

"akkor sem tennék halálfejes szolgáltatás alá SATA diszkre."
-->"daráljon le egy kiló bélszínt, a macskámnak viszem!" Ha telik rá, tedd nyugodt szívvel! Legfeljebb "megáll a kés, a hentes néz..."

"És nem feltétlen a teljesítmény, hanem inkább a megbízhatóság miatt (SATA vs. SAS). "
Ha elromlik, kicseréled, függetlenül attól, hogy SAS vagy SATA.
Az élettartam alatti (esetleges) diszkcsere-növekedés többletköltségei aligha viszik el a SAS->SATA megtakarítást. Persze, ki kell számolni: minden helyzet más lehet.

"Ha jól értem, te valamiért a mailarchiválás ellen vagy. Vagy rosszul értem?"
Igen, rosszul. Mindig a konkrét igények ismeretében lehet csak megtalálni és mérlegelni a lehetséges megoldásokat.

Üdv,
Marci

"Igen, rosszul. Mindig a konkrét igények ismeretében lehet csak megtalálni és mérlegelni a lehetséges megoldásokat."

Akkor nem értem, hogy mi a gond azzal, hogy az éles szerveren csak X ideig őrizzük meg a leveleket, a mailboxok méretét igyekszünk kontroll alatt tartani, viszont nem kötünk kompromisszumot a SATA felé. A gyakorlatilag sosem kellő leveleket (az archívumon 28 fajta auditálási típust tudok beállítani, így pontosan tisztában lehetek az archívum kihasználtságával kapcsolatban) automatikusan elmozgatjuk egy lassabb de olcsóbb archívumba (pont ez a SATA területe, erre javasolják a gyártók), aminek egyébként az elérése az Outlook-ból, webes felületen, saját vastagklienssel és mobiltelefonról is megoldott - így nem kényelmetlen az elérése.

Ráadásul az archívumban való keresés sokkal kifinomultabb az Outlookénál (amit - azért lássuk be - nem túl nehéz elérni :), nem beszélve arról, hogy minden, az archívumon végzett művelet nem a mailszervereket terheli.

Ez szerinted az ördögtől való elképzelés?

--
trey @ gépház

Hát igen. Csak aztán győzd adminisztrálni, bírd licencekkel, meg verj rajta végig egy migrációt, ha elért az életciklusa végére. Kérdés, hogy mennyivel bonyolítod meg az életed ezzel, mit nyersz rajta. Van egy szint, ami felett az ember elmegy ebbe az irányba. De azért felénk nem ez a jellemző.

Egyébként mindamellett, hogy igaz amit írsz, az általam használt - és jónak gondolt - megoldást elég sokan használják:

Deutsche Telekom
Hewlett-Packard
Hitachi Data Systems
JVC
Multiband Information Technologies
T-Systems
Yahoo Japan
Bosch
Kawasaki
KTM
Olympus
Seiko Instruments
Siemens
ThyssenKrupp
Volkswagen
GE Healthcare

Meg egy csomó egyéb cég. Szerintem jó okkal.

--
trey @ gépház

( _Franko_ v | 2015. 05. 20., sze – 09:39 )

Az előző munkahelyemen 200MB volt a mailbox mérete és nem volt központi archiválás, a mostani munkahelyemen fogalmam nincs, mert nem használom a céges levelezést, egyszer kellett levelet írnom márciusban, akkor derült ki, hogy novemberben lejárt a jelszavam... :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Valószínűleg az ő érdeke és a cégvezetés érdeke (költségek minimalizálása) nem találkozik, így nem nyerhet. Ráadásul nekem sem kellene sokat dolgoznom azon, hogy bebizonyítsam, az x éven túli leveleket értelmetlen mailszerveren pörgetni, azok mehetnek az archívumba (főleg úgy, hogy a mail archiválás vezetés oldali igényként (is) került bevezetésre :D).

Egyébként pedig senki sem tiltja meg a felhasználóknak, hogy a mailszerver, a központi mentés és központi archiválás mellett a saját gépére olyan archívumot gyártson, amilyet szeretne.

--
trey @ gépház

Tiltani senki nem tiltja, de vajon vannak-e okitva erre? Sajnos ma meg mindig az a problema, hogy a hetmillio informatikai analfabeta orszaga vagyunk, nem is tudjak hasznalni az eszkozeiket, illetve nem is tudjak megoldani a problemaikat kulso segitseg nelkul.

Persze, ez a te oldaladrol koltoi kerdes, hiszen ezert - elvben - nem az uzemeltetoknek kellene felelni.
--
Blog | @hron84
Üzemeltető macik

és központi archiválás mellett a saját gépére olyan archívumot gyártson,

ahol csak hallottam rola [hogy bevezettek az email archivalast], a juzerek imadjak a kozponti archivumot. Nagyfoku elvetemultseg kell ahhoz, hogy mellette valaki pl. pst-ket fabrikaljon a sajat gepen. Nincs is ertelme.

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Akkor át kell állni a Google Apps vagy a Office365 rendszerre...

...én nekiálltam timesheet-en könyvelni napi 20-40 perceket arra, hogy leveleket törlök, különben nem tudok dolgozni, aztán két hónap után odamentem a főnökhöz, hogy lám, nekem ez a havi 20 napból elvisz egy napot, az órabérem X forint, mennyibe kerül nagyobb postafiók...

...aztán az üzemeltetésen lepattant a dolog azzal, hogy maximum 400MB-ot tudnak adni, mert a CEO-nak van 500MB és hogy nézne ki az, hogy egy utolsó senkinek több van.

Na, én meg úgy döntöttem, hogy ha ennyire nem tudnak munkaeszközt adni, akkor inkább máshol dolgozok. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

..aztán az üzemeltetésen lepattant a dolog azzal, hogy maximum 400MB-ot tudnak adni, mert a CEO-nak van 500MB és hogy nézne ki az, hogy egy utolsó senkinek több van.

ez melyik ceg? :-)

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

"Akkor át kell állni a Google Apps vagy a Office365 rendszerre..."

Éppen most csinálok egy 10 fő alatti cégre (ahol baromira nem lenne indokolt és anyagilag is hülyeség) Exchange szervert, mert Office 365 volt az ajánlat, de hallani sem akartak arról, hogy a leveleik a cég falain kívülre kerüljenek.

Egy másik most költözik vissza a felhőből Exchange-re. Soha nem akarnak többé felhőbe menni.

Nem mindenhol opció a felhő.

--
trey @ gépház

"de hallani sem akartak arról, hogy a leveleik a cég falain kívülre kerüljenek"

Ahja... aztán mobiljuk sincs, ugye? :)

Ismerek én pár ilyet, ahol mindent a cég falain belül akarnak tudni, aztán meg folyamatosan panasz van, hogy a versenytársak olcsóbbak, gyorsabbak, jobbak, de nem értik, hogy miért, amikor ők pedig már tényleg mindent saját maguk csinálnak, a versenytársak meg egy csomó tevékenységet kiszerveztek, ami nyilván drágább meg kockázatosabb...

"Egy másik most költözik vissza a felhőből Exchange-re. Soha nem akarnak többé felhőbe menni."

Mi volt a legfájdalmasabb dolog, ami miatt ezt meglépték?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Internetproblémák, ahol vannak, ott nem is lesz jobb, ami van az naponta 5-6 alkalommal áll le."

Ez még érthető is akár...

"a privacy aggályok"

Ahja... ebből nekem mindig az a furcsa, hogy végtelen mennyiségű startup képes a cloud-ban működni, pedig azoknak van a legnagyobb esélye és veszélye arra, hogy valami olyat lehet lenyúlni, amivel tényleg robbantani lehet a piacon... és mégis azok a cégeknek vannak privacy aggályaik, amelyeknek minimális a vesztenivalója és tulajdonképpen a kutya se kíváncsi a levelezésükre vagy a belső működésükre...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Vannak zavarosban halászó cégek is, akik akár a bűncselekményektől sem riadnak vissza *. Nyilván ezek nem szeretnének semmilyen bizonyítékot. Laikus fejükkel azt hiszik (gondolom én), hogy ha saját szerverük van, akkor az a tuti.

* Pl. sok évvel ezelőtt találkoztam olyan ügyféllel, aki zöld mezősben berendelt egy komplett informatikai hálózatot. Minden rendben tűnt vele, az illetékesek lecsekkolták a hátterét, de amikor mentem telepíteni, az ajtajuk le volt ragasztva mint egy bűnügyi filmben, a tulajt éppen bilincsben vitték el, a pénzügyőr pedig azt mondta, hogy itt telepítés nem lesz, mert milliárdos cukorcsalás a gyanú.

Szóval ilyenbe is simán bele lehet futni. Ha valaki titkolózik, annak számos oka lehet.

Csak, hogy teljes legyen a kép, egy másik cégnél éppen most migrálok egy szervernyi Exchange felhasználót O 365-be :) Szóval oda-vissza vannak költözések.

--
trey @ gépház

"Vannak zavarosban halászó cégek is, akik akár a bűncselekményektől sem riadnak vissza."

Pláne egy indok, hogy ne helyben legyen, amit pillanatok alatt lefoglalnak... :)

"Ha valaki titkolózik, annak számos oka lehet."

Szerintem alapvetően nem titkolóznak, csak van egy irracionális félelmük a kiszervezett feladatokkal kapcsolatban, drágának gondolják, mert egy fura elgondolás alapján a saját munkaerő "ingyen van"...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nem, nem arrol van szo, hogy draganak gondoljak, hanem arrol, ami itt is felmerul allandoan a HUP-on, hogy majd a Microsoft/Google/Amazon biztos jol belenez a levelezesbe, es micsoda dolgokra fogjak felhasznalni.

Ezek az emberek egyvalamit felejtenek el: a nyilvanos szocialis halos eletuk es a bongeszesi elozmenyeik elemzese tobbet elarul roluk, mint akarmilyen titkosirassal irt level a baratnonek, felesleges ebbe penzt es energiat fektetni (marmint a levelek tobbszintu feldolgozasara).
--
Blog | @hron84
Üzemeltető macik

Hat, ami az O365 minoseget es Microsoft hozzaallasat illeti a supporthoz, meg is ertem. Sztori: Van egy nagy ceg, 100+ user, O365-ben vannak, meg van ADFS is. Veletlenul sikerult torolni valami usert, amivel a szinkron zajlik (csak kollegatol tudom, nem latom at annyira ezt a reszet), emiatt megallt a levelezes, ket napon at ment a pingpong a globalis es a magyar support kozt, hogy ugyan kinek van jogosultsaga segiteni, majd miutan egyre hangosabban vertuk az asztalt, valahogy eljutottunk egy mernokhoz, aki kb. tizenot perc alatt helyrerangatta a rendszert. Ket napig nem volt a cegnek levelezese.

Azota en mindenkit ova intek az O365-tol. Nem azzal van a baj, hogy nem lett meg 72 ora alatt a hiba megoldasa, hanem az, hogy egy effektive 10 perces hibabol 48 orasat sikerult generalni, mert ostoba modon van felepitve a support. Es mint fizeto ugyfel, nem erdekel, hogy az ISO, az ITIL, vagy valami mas miatt van ez igy, az a modszertan, ami ilyen szervezest igenyel, kidobando.
--
Blog | @hron84
Üzemeltető macik