Fórumok
Üdv!
Olvasgatom a neten a fórumokat (hup :)), doksikat és az alábbi MS Exchange alternatívákat találtam (ami tetszett is):
* Zarafa
* Zentyal
* OpenChange
* Sogo
Ahogy látom, kapcsolat is van köztük.
Mindegyik szimpatikus, van olyan amit egyszerű feltelepíteni (pl. Zentyal).
Ki melyiket használja? Miért (pl. előnye)?
Ha jól láttam, akkor a Zarafa kivételével a többi korlátlan számban kiszolgálja az Outlook klienseket (ingyenesen). De ha tévedek javítsatok ki!
--
G.
Hozzászólások
Zentyal alatt nem Zarafa fut? (Ha jol tudom korlatozott szamban ingyenes csak a zenytal-ban is a csoport levelezes)
Igen, én is valami hasonló kapcsolatot véltem felfedezni:
Zarafa -> Zentyal?
OpenChange -> SOGo?
--
G.
A friss 3.4-es alatt már SOGo van.
Csak elfelejti feltenni, és konfigurálni a postgresql-t, ill. engedélyezni kell az apache-hoz tartozó konfigot.
Egyébként szépen át design-olták.
Szerk: és az nginx-ből is ki kell szedni, hogy http 80-on listeneljen, mert oda a haproxy menne.
Most nézem virtuális gépben, hogy a Zentyal alatt is OpenChange modulokat irogat (OpenChange, OpenChange Webmail).
--
G.
OpenChange Webmail = SOGo
Elég vad dolgnak tartom, hogy egy laza huszárvágással gyakorlatilag kikukázták a Zafara-t és bekerült a SOGo.
Nem a SOGo-val és nem a Zafara-val van bajom, hanem a folytonossággal, azaz a hiányával.
A SOGo is egy komplett rendszer, mint a Zentyal. Bár a Zentyal-ban mintha több funkciót látnék.
A SOGo-t is felteszem egy VM gépre egyik nap és megnézem.
Egyébként egy korábbi (talán 2012-es) hup-os fórumtémában olvastam - ha jól emlékszem - slapic-tól, hogy sajnos ezek a rendszerek lettek a "kvázi szabványok" (Exchange, Notes). Egyetértek vele, de sajnos sokan ezeket használják.
Nem lenne rossz egy kimondottan Linuxos alternatíva, ami nem pl. az Exchange-hez igazodik. Egy "Linuxos szabvány". :)
--
G.
Erre ott a Kolab: közismert protokollok (POP3, IMAP4, LDAP, SMTP, CardDav, CalDav, WebDav, HTTP, ActiveSync) felett egy raklap standardizált (talán a standard 3. verziójánál tartanak) tárolómechanizmus (IMAP folderekben XML fájlok). Cserébe a Kontact out-of-the-box, a Thunderbird/Evolution pluginnel támogatja*, oszt jónapot, ha Outlook-ba akarod bevarázsolni akkor licensz-köteles konnektor plugineket kell venned.
*: A standard protokollok miatt legalább olvasási szinten mással is lehet hozzá csatlakozni, de nem lesz teljes...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Ennél sokkal több az Exch (menedzsment, tárolás, cluster, mély AD integráció, mobileszközök terén) DE inkább arra kellene rámutatni, hogy lehet sokkal jobban szervezni a workflow-t (mondjuk egy issue kezelővel és IM-el), ott, ahol mindent Exch-be hánynak.
Erről órákon át vitatkozhatnánk (és maradnánk a vélemények szintjén, mert nincs optimális válasz), hogy ebből mennyi az, amit elkülöníthetetlen részként egy szoftverbe kell implementálni (tárolás és indexelés, clusterezés etc.). [pl. valamelyik Linuxos groupware cikknek álcázott fizetett hirdetésénél a HWSW-n a kommentek közt ha jól emlékszem Auth Gábor hosszasan vitázott a többiekkel]
A másik oldalról: egy tisztán Linux-os rendszerbe nem feltétlenül kell a "mély AD integráció", mert nincsenek AD klienseid. Azért az AD továbbra is csak egy overglorified multi-master LDAP/Krb implementáció, amibe a Windows szervertermékek előszeretettel hánynak be minden infót.
Szerk.: Amúgy én radikálisabban állnék a dolgokhoz egy új implementációnál, kapásból kihúznám a meglévő protokollokat (leginkább az SMTP, afölött már nagyon eljárt az idő) és visszafelé-kompatibilitás nélkül újra kezdeném.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Miért, mi a baj az SMTP-vel? Régóta kiválóan működik.
Van biztonságos változata is ugye, az SMTPS.
Talán az a gondod, hogy bárki nevében küldeni lehet vele emailt?
Erre meg ott vannak a digitális aláírások + a titkosítás, ha nagyon kell.
Gyors is, könnyen konfigolható (mármint általában) és meglehetősen stabil is.
Nekem a szerverüzemeltetés során ezzel van a legkevesebb gondom. Minden más szolgáltatással (Samba, LDAP, http, ftp, stb.) csak a szívás van. Talán még a DNS szolgáltatás az, amihez ezer éve nem kellett nyúlnom.
Mi lehet még vele a gond?
--
nTOMasz
"The hardest thing in this world is to live in it!"
Az, hogy nagyjából senki nem úgy használja manapság, ahogy eredetileg tervezték (mindenki önmagában szerver), és az eredeti tervek miatt lehet visszaélni vele (spam, fenti bárki bárki nevében írhat stb.).
Szerk.: A kávé alatt rájöttem, hogy illene kicsit pontosítanom. Ha úgy nézzük, akkor valóban, az SMTP nagyjából teljesíti a követelményeket (többnyire eljutnak a levelek A-ból B-be vagy ha nem, akkor többnyire visszajön egy levél A-hoz, hogy hupsz); viszont a protokoll tervezési hiányosságai miatt világszinten rohadt sok erőforrást pazarlunk el erre, mert a levélforgalom nagyon nagy százaléka spam, amit valahogy szűrni kell (és a szűrés helye előttig továbbítani, így sávszélesség, számítási kapacitás, tárolókapacitás megy a levesbe a spam miatt).
Ha megkülönböztetnénk szervereket és klienseket, akkor azonnal el lehetne dobni azokat a kapcsolatokat, amik nem bejegyzett szervertől jönnek (bejegyzett szerver: pl. a reverse zónában PTR rekordok, hogy melyik domainek nevében küldhet levelet ill. a forward zónában is jelölni kell minden szervernél IP címmel, hogy az szerverként viselkedhet az adott domainre). Viszont domaint regisztrálni egyszerű, így a következő lépés: digitális tanúsítványokkal igazolja egy felsőbb szintű party (szolgáltató, akárki), hogy az a szerver tényleg a domain tulajdonosának nevében jár el és kezességet vállal arra, hogy nem spamel. Ha meg az aláíró abuse címén bejelentenek egy spam-et egy crl/ocsp ellenőrzésen máris megbukott a szerver, mehet a kukába) - persze ehhez az kell, hogy ezeket kötelezően előírjuk protokoll szinten és ne azon menjen a szüttyögés, hogy hányadik extension-t dobjuk hozzá az SMTP-hez, hogy legalább NÉHÁNY szerver visszaírja, hogy mekkora levelet fog eldobni... [az is megérne egy próbát, hogy végignézik az elmúlt két évtized összes SMTP extension-jét és a GMTP [Good Mail Transport Protocol :) ] core részévé teszik a hasznosakat]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
(Ha mar az eddiginel jobban belekeverjuk a DNS-t az SMTP-be, akkor en sokkal inkabb SRV / TXT rekordokkal hangolnam tovabb, mintsem valami speci trukkel az A/PTR rekordokat okositanam fel. De ez csak ugy kb 15 sec gondolkodas utan, szoval agyontesztelve nincs a dolog.)
Eredmény szempontjából mindegy, a mostani helyzetnél minden csak jobb lehet szvsz., de sajnos egy fecske meg a nyár... túl elterjedt, hogy lehessen velek kezdeni valamit.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Nos, a sok levélszemét miatt nem lehet az SMTP-t hibáztatni.
Sajnos az emberi butaságot nem lehet kiszorítani, még akkor sem, ha SMTP helyett GMTP lenne.
--
nTOMasz
"The hardest thing in this world is to live in it!"
Valóban nem lehet, amikor tervezték, akkor a célját ellátta - csak azóta a környezet masszívan megváltozott (userek száma, felhasználás módja stb.) így megéri a "hibáit" (előre nem látott környezetváltozások miatti tervezési hiányosság, nevezzük akárhogy) kihasználni. Viszont ezeket bezárni visszafelé kompatibilis módon nem lehet, ezért kéne az egészet beszántani :)
Az emberi butaság valóban nem kiszorítható, de az SMTP-vel sem az a baj, hogy nagy az állatkert, hanem hogy alacsony a kerítés: technikailag nincs különbség mondjuk egy kormányszerv mail szervere és a 14 éves Pistike botnetbe tartozó gépe között - mindkettő érvényes mailszerver (és igen, még egy körben körbetaknyolhatjuk a fél világot, hogy opcionálisan javíthassunk a helyzeten a SPF/DKIM-mel, de nem tehető kötelezővé - a fenti hasonlatnál ez kb. annyit tesz, hogy a 10 km hosszú kerítést 50 méteren megemeljük...).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Hát pedig pont az SPF/DKIM szép lassú kötelezővé tétele lenne a megoldás. Szerintem. Mondjuk azt lehetne mondani, hogy 2015 dec 31 után akinek nincs, az nem fog működni. Új szervert meg mondjuk már 2015 január 1 után nem felengedni a hálóra. Ezt gondolom ISZ szinten lehetne meglépni a világ országaiban.
És ezzel egyet megoldottunk a problémák közül; ráadásul közben csináltunk egy új Y2K-t, mert amint utólag kötelezővé teszel valamit, azt eltöröd: messze nem csinálná meg mindenki az átállást (őket ezzel ki is zártuk minden visszirányú kommunikációból), ahol meg is csinálják emberi mulasztás miatt kimaradhat 1-1 host, ami katasztrofális eredménnyel járhat (ja, bocs, elfelejtettem, hogy a lélegeztetőgép önmagában játszik SMTP-t, sry, de a fogadófél hibája, hogy a hibás SPF miatt eldobta a riasztást, hogy fulladozik a beteg) stb.
Személyes vélemény, de szerintem 1) olyan mélyen beágyazódott az e-mail 2) annyira eljárt felette az idő és 3) annyi rosszul bekonfigolt szerver van, hogy azon kívül, hogy nulláról újra kezdjük, nem sok mindent lehet vele kezdeni.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Open-Xchange ?
Mikor utoljára néztem - igaz nem mostanában volt -, nem igazán akart összejönni.
Most még csak a honlapjuk sem akar bejönni. Bár ez lehet, hogy valami pillanatnyi probléma.
--
G.