Levelezés tárhely szolgáltatónál (pl. mikrovps)

Web, mail, IRC, IM, hálózatok

Sziasztok,

Mennyire lehet életképes és használható közepes felhasználói szám esetén (50-100 fiók), egy tárhely szolgáltató rendszerét használni levelezésre?  A tárhelyhez kapcsolt Cpaneles email szolgáltatásra gondolok.

Tesztelési célokból kipróbáltam a mikrovps rendszerét, logikus felépítésű, könnyen használható levelezési hátteret biztosíthat több domain számára is.

Van ennek valamilyen hátulütője? Összehasonlítva például egy Exchange online-al (csak a levelezés természetesen) mennyivel térhet el a szolgáltatás minősége, rendelkezésre állása?

Esetleg más szolgáltató is számításba jöhet, ami hasonló Cpaneles rendszert használ mint a Mikrovps.
Negatív példa számomra az Ionos, ahol a menedzsment felület átláthatatlan, kaotikus, olyat nem szeretnék..

Köszönöm!

( STP | 2021. 09. 27., h – 13:34 )

Szerkesztve: 2021. 09. 27., h – 13:35

Nézzük...
single node vs cluster
single site vs multi site
Support elérhető emberi időben vs írhatsz levelet

És az egyéb 'apró' kérdések: dns beállítás levelezéshez, spam szűrés, vírus szűrés, karantén, auto-reply (pl: ooo) beállíthatóság, ddos 'védelem'

Ebből ami biztosan van (láttam) pl, a fenti szolgáltatónál, az a DNS beállítás, spam szűrés, auto-reply
Ad hozzá webmailt (naptár, címjegyzék támogatással), multi domain kezelést, egyedi fiók beállításokat (pl. kimenő, bejövő forgalom tiltása, kvóta), mobil eszköz beállítási konfigurációs fájlok bár ezeket nem próbáltam. A mentés is egyszerű, mivel a tárhely maildir könyvtárában jelennek meg levelek.

Van értelme ilyen megoldásban gondolkodni, használják ezt így? Vagy inkább a drágább, de talán megbízhatóbb MS vagy Google szolgáltatást célszerű bevezetni?

Szia!

Én saját ügyfeleimnek így adok levelezést. Én ISPConfig rendszert használok, de egy CentOS Web Panel is tud mindent ( legtöbb helyen Cpanel lesz, az is ). Van olyan VPS-em ahol megvan a közel 100 fiók, 400 Gb körüli adatmennyiséggel. Naponta mentem magamnak VM szinten is, meg fájl szinten is. mail-tester.com szerint 10/10-re beállítva minden a DNS-ben, DKIM, DMARC, SPF... Közel sem kérek tőlük annyit összegben mint amiben az O365 kerülne nekik. Pl van több olyan fiók amiben pár 100 Mb levél van, de kell működnie. Vannak olyanok amiben 40-50Gb. Szerintem ebben a 100 körüli fiók méretben ezek még teljesen jól kezelhetők. Nagyobb cégnél már úgy is komoly AD van, ott szinte adja magát, hogy O365-höz nyúljanak.

almát a körtével.

Ez igaz.

O365 4.20 email fiók/hó. Van 10 postafiókod, aztán már évi 500 eurnál jársz. Egy nagyságrenddel kerül többe mint egy klasszikus shared/mail hosting.

De nem is veszik el a teljes levelezés, ha úgy hozza a sors. De ha melósonként és havonta nincs 1500 forint erre (ez a medián bruttó bér 0,5 százaléka), akkor az a levelezés valóban nem fontos, akár el is veszhet. Viszont tapasztalatom szerint pont az ilyen ügyfelek a legrosszabbak, akik minden egyes fillért jól megbasznak.

https://iotguru.cloud

Sajnos ezek nem mutatói a tökéletességnek. Lásd korábbi linkem, ahol az outlook egyik szerverének el volt gépelve a reverse dns bejegyzése, így hibára futottak az onnan kiküldött levelek.

Ez bárkivel megtörténhet, de hol volt a visszaellenőrzés a nagy ISO folyamatok között?
Ilyeneket egy pistike bt-től elnézünk, de egy MS-től nagyon gáz.

( andrej_ v | 2021. 09. 27., h – 14:23 )

Nagyon egyszerű. Számolj. 50db Exchange online az kb EUR 200 EUR 170 havonta az 50GB-os fiókokkal, ami kb 62e forint lesz, illetve simán több, hogy ha olyan a középárfolyam és pláne a váltási. Ad-e neked annyi pluszt az Exchange Online, hogy megérje ezt a mértékű ráfordítást?

Tehát évente alsóhangon kifizetsz 720-750k forintot az MS-nek. Are you sure? Yes No Cancel.

Pont ezért vetettem fel a kérdést. Ha megbízhatóságban nem sokkal rosszabb a tárhely szolgáltatós megoldás, akkor valós alternatíva lehet. Viszont az, hogy csináltam benne 2 domaint és 6 email címet és teszt leveleket küldtem ide, oda még nem sokat mond a megbízhatóságáról.

Esetleg ha valaki próbálta már, megoszthatná a tapasztlatait.

Én szolgáltatók emailt szintén, nekem jók a saját szolgáltatásommal a tapasztalatom. :) Általában a felhasználók visszajelzése is az, hogy jól szoktunk működni levélügyben. Igaz nem CPanel, hanem egyedi, és ekkora léptékben mint nálad, saját IP címet szoktam javasolni. Másrészt a shared hosting elsősorban tárhelyre és nem per fiók számláz.

( Proci85 v | 2021. 09. 27., h – 15:03 )

Szerkesztve: 2021. 09. 27., h – 15:04

Microsoft felhős levelezőjét akkor sem használnám, ha fizetnek érte.

Linux szerver oldalon csomót szívunk az o365/outlook fiókokba való levélküldéssel és nem mi vagyunk a gyökerek.

Az, hogy ok nélkül /24.../20 tartományokat kitilt az o365, az elég meredek. Support meg nem sokat tud érdemben segíteni.
Aztán lehet magyarázkodni az ügyfélnek, hogy miért nem érkezik meg a levele az o365-ös fiókjába és ez az állapot hónapokig fennáll, majd hirtelen megjavul. Aztán 1 évre rá hirtelen megint visszapattannak a levelek. Vállalhatatlan az egész. Nagyon sok szívást okoztak az évek során.

Minden szavaddal egyetértek!

Anno még hosting rendszergizda koromban szinte folyamatosan problémáink voltak velük. Ügyfél szól, hogy nem érkezik meg a levele office fiókba, pedig mail-tester-en 10/10-esek vagyunk és a logok szerint minden rendben. Nézzük hát mit mondd az MS. Beszéltünk velük chaten is, meg telefonon is, de a válasz mindig ugyanaz: "Úgy látjuk, hogy minden rendben." Mondom nekik nagyszerű, de elküldjük a levelet és soha nem érkezik meg, miközben a logokban látjuk, hogy az ő rendszerük elfogadta azt, azaz valahol náluk megy félre valami. "Értjük, de mi úgy látjuk, hogy minden rendben működik."... És nem jutsz ezen túl, mintha nem is emberrel beszélnél (lehet, hogy valóban nem), hanem valami robottal.

Aztán magyarázd meg az ügyfélnek/főnökségnek, hogy nem a mi rendszerünk a sz@r, hanem a trillió dolláros cég rendszere...

Azóta webfejlesztőként keresem a kenyerem, de kétszer már így is belefutottam, hogy az ügyfél azt kérte, hogy használjuk az office-os e-mail címét a weboldalon levél küldésre, ami egyszer nem engedte a szervert csatlakozni mert csak... másodszor pedig az api olykor random módon eldobta a leveleket.

Szóval az o365-öt senkinek nem ajánlom. Egy nagy rakás katyvasz az egész szolgáltatás. Azóta ha ügyfél kéri, hogy kössük be a náluk hosztolt címét a weboldalába simán megmondjuk neki, hogy nem lehet és inkább keresünk neki más megoldást.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Pl a Postfix logokban láthatod a saját rendszereden, hogy sikeresen el lett-e küldve a levél. Az o365-től mindig az jött vissza, hogy 250 ok, mail sikeresen megérkezett, de a valóságban nem mindig érte el célját a levél.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Ugyanolyan message trace van, mint egy onprem exchange-ben, sőt lehet még okosabb egy kicsit. Ez persze az admin szintű felhasználó hozzáférésében van, de jellemzően nagyon kevés bejelentés jön, amit vizsgálni kell.

Az sokkal nagyobb gond, hogy sokan észnélkül elszállnak a felhőbe (lehet a káposztásbabos csapatépítő után) és elfelejtik az SPF rekordot és társait módosítani, majd csodálkozik a kedves pártner, hogy húha nem jön meg tőlük a levél.

Ez egy érdekes kérdés, nekem pl semmi panaszom az o365 levelezéssel, pedig nem egy fiókom van. Oké, mostanában nem használom nagyon intenzíven a mailt.

Szerintem ők úgy vannak ezzel, hogy ilyen tömegkiszolgálásnál nem lehet / nem éri meg utána menni az egyéni panaszoknak, tömeges jelenségeket néznek csak, és náluk 99.99% minden rendben van.

Ettől függetlenül az a 0.01% ember akár sok is lehet és nekik a saját szemszögükből "nagyon rossz", szintén érthető.

Gábriel Ákos

Ez teljesen rendben van és érhető is, de akkor legalább kötnének az ember orrára annyit, hogy bocs haver, blokkolva vagy mert SPAM gyanús tevékenységet folytatott valaki ebből a tartományból 2 évvel ezelőtt. Mint ahogyan ezt pl a Google simán megtudja tenni.

Javítottam szervereket, amin feltörtek weboldalakat, hogy spammeljenek róla ezért a Gmail letiltotta az IP címüket, viszont ott mindig ott volt az adott SMTP válaszban, hogy IP címedet bannoltuk SPAM gyanús tevékenység miatt, ha fellebbezni kívánsz itt a link... (persze ez most csak az én megfogalmazásom, nem tudom már fejből, hogy hogyan is szólt pontosan a hibaüzi, de a lényege ez volt). És ha követted a linket, kitöltötted a formjukat megindokolva, hogy mi történt és milyen lépéseket tettél a hiba javítására, jövőbeni elkerülésére, akkor akár pár óra múlva máris engedtek küldeni.

Ehhez képest az MS-nél konkrét supportossal beszélsz és kiszúrja a szemed annyival, hogy "Úgy látjuk, hogy minden rendben van."...

A probléma a hozzáállással van. Nem szimpatizálok különösebben a Google-el sem, mint céggel, viszont ott legalább adnak neked lehetőséget ártatlanságod bizonyítására, a hiba orvoslására, míg az MS kb azt mondja, hogy "szerintem te SPAMMER vagy és lesz@rom, hogy mint mondasz".

Mindenki döntse el magának, hogy neki melyik attitűd a szimpatikusabb, de a magam részéről ezerszer inkább választanék Gsuite, vagy hasonló szolgáltatást, mint o365-öt.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Ez teljesen rendben van és érhető is, de akkor legalább kötnének az ember orrára annyit, hogy bocs haver, blokkolva vagy mert SPAM gyanús tevékenységet folytatott valaki ebből a tartományból 2 évvel ezelőtt. Mint ahogyan ezt pl a Google simán megtudja tenni.

Minő meglepetés, az O365 is képes erre.

Ehhez képest az MS-nél konkrét supportossal beszélsz és kiszúrja a szemed annyival, hogy "Úgy látjuk, hogy minden rendben van."...

Nem lehet, hogy rossz helyen vagy rossz kulcsszavakkal kértél támogatást?

https://iotguru.cloud

Minő meglepetés, az O365 is képes erre.

Biztosan képes, de én anno (kb 3-4 évvel ezelőtt) nem nagyon láttam rá precedenst. A legkomolyabb error log, amiket eltudtunk fogni azok is kb connection refused szintűek voltak. Zero explanation.

Nem lehet, hogy rossz helyen vagy rossz kulcsszavakkal kértél támogatást?

Előfordulhat, de töltöttünk ki nekik formokat, hoztunk létre support ticketet, chateltünk velük a weboldalukon keresztül, egyszer telefonon is ment a terefere velük, de az esetek nagy részében nem túl sok sikerrel. Volt, hogy diskurálás után pár órával később átmentek a levelek, de volt, hogy csak hetekkel később, aztán pár hónapra rá megint nem. Olyan szeszélyes volt az egész, mint az évszakok. :D

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Az a baj, hogy megkövetelnek egy csomó dolgot (ami önmagában nem lenne baj, sőt helyes), de ők nagyjából semmit nem tartanak be, és azt is megváltoztatják random, értesítés nélkül.

Először is, hogy nem lehet szürkelistázni, mert sohasem sikerül ugyan arról az IP című kimenő szerverről újraküldeniük a levelet, ami alap elvárás lenne RFC szerint is. Aztán napokkal később megint ugyan arra az IP-re esik a próbálkozás, és akkor átmegy, vagy nem, mert kifutott a várakozási időből a greylist. Ezt valahogy az összes többi nagy meg tudja oldani. Aki nem akar szívást, kivételbe veszi a nagyjából 200 ezer (!) IPv4 címüket a szürkelista szűrésben.

Aztán néhány hete az okozott egy napos fejtörést, hogy kitalálták, a küldő szerver neve és a HELO/EHLO név nem egyezik meg. Van is rá hivatalos oldaluk, ahol magyarázzák, hogy terhelés elosztás és a méreteik miatt szükséges ez. Igaz, a többi nagynál nincs ilyen hülyeségre szükség. Ugyan mindkettőnek van DNS bejegyzése és jó reverse rekordja, de akkor is, alap szűrés volt eddig (talán még RFC is van rá), hogy a kapcsolódó gép neve, a címéből a reverse és a HELO név egyezik. Erre megint kivételt gyártani, ami az Ő névtartományokat, és IPv4 tartományukat (mondom, 200 ezer cím van megadva a weboldalukon javasolt kivételnek, ami nyilván nem a levelező szerverek száma, hanem a fél Azure...) kiveszi az ellenőrzésből.

Persze a szokásos, hogy alapból a világ minden címe tiltva van, és úgy kell kucsorogni, hogy ugyan a teljesen legitim és minden elvárásuk szerint beállított szerverem hadd küldjön már nekik levelet... Megalázó és egyben nevetséges. Ilyen sincs egyik másik nagynál sem.

Tessék szelektíven szürkelistázni reverse alapján, meg reverse hiány esetén. Postfixben és Eximben is elég egyszerűen megoldható és évek óta ez a rendesen működő dolog. Ráadásul a szürkelista egyre kevésbé véd, mert jellemzően nem random béna SMTP-kről jön a matéria, hanem malware-rel felnyalábolt SMTP accountokból.

A szelektív greylist, vagy legalábbis erősen whitelistelt, mellett szól az is, hogy egy O365 vagy Google cloud, az úgysem ezen fog fennakadni. Nálam jellemzően bevált, nincs ezzel probléma. Az sokkal többször előfordul, hogy a kedves feladó elhaladt a felhőbe, de agyilag nem követte és az SPF rekordot nem hangolta után.

Nem az a kérdés, hogy megoldható-e és hogyan. Meg a greylist már kifutóban van, csak ez volt évekkel ezelőtt az első kellemetlen élményem az O365-tel. Hanem az a gond, hogy ezek a problémák amitket írtam kizárólag az O365-nél fordulnak elő, a többi nagynál nem. Valahogy nekik sikerült a levelezést úgy felskálázni, hogy az addig elfogadott, bevezetett "szabályokat" betartották továbbra is. Kivétel lett az MS, mert ők általában mindent jobban tudnak a világ többi részénél, meg azt is tovább fejlesztik, ami már addig is túl jó volt. És rá is erőltetik mindenkire, bármiféle egyeztetés vagy konszenzus nélkül...

Először is, hogy nem lehet szürkelistázni, mert sohasem sikerül ugyan arról az IP című kimenő szerverről újraküldeniük a levelet, ami alap elvárás lenne RFC szerint is.

Először is a greylisting a saját magad szopatása, másodszor ez melyik RFC melyik pontja, hogy ugyanarról az IP-ről kellene kimennie?

https://iotguru.cloud

Kerestem gyorsan kettő esetet, de időnként felbukkan a hiba más topikban is. Hidd el, több IP tartományban, több szerverről szívtam velük én is, más is.

Volt olyan IP tartományból is szívás, ahonnan tudom, hogy baromi szűz, évek óta a kezem alatt van, steril gépek vannak, a teljes IP tartományból alig aktív pár IP  és nem tudtam az o365 felé küldeni, mert 5 tartománnyal odébb _másik_szolgáltatónál valami spamet érzékeltek. A 2 subnet ripe adatbázis szerint is más céghez tartozik, tehát még csak össze sem lehet mosni a kettőt. Egyszerűen idióták és megtehetik....

https://hup.hu/node/155110

https://hup.hu/node/172717

 Hidd el, több IP tartományban, több szerverről szívtam velük

Pont ugyanígy csak én nem szívtam/szívok vele. Sőtt vps bérlés esetén is pár perc alatt sikerült leszedetnem az adott IP-t a listájukról, és azóta is megy minden gond nélkül feléjük arról a címről is.

Lehet jobb szomszédaid vannak.

Amúgy meg baxák meg. Miért kell leszedetni valamit, ha nem indokolt a felkerülés? Ilyenneket amúgy játszottam, ideig óráig jó volt. Most épp jó megint, de fél éves ciklusokban hullámzó az eredmény. Más is hasonlókról számolt be itt a hupon, lásd pl. linkelt kommentek.

Kicsit olyan érzésem van, mikor a spammer irja a levél alján, hogy itt iratkozhatok le. Mire fel, ha nem iratkoztam fel?

Ha spammelnek egy szerveremről, megértem. De nem, ártatlan vagyok :)

Épp most visznek el tőlem 65 postafiókot, 2 VPS dedikáltan az övék, 500 Gb levél kb. Mert nekik nincs idejük erre, hogy be kell állítani a gépen a postafiókot és így nem kapnak meg leveleket és mennyi mindent elbuknak és neki 4 gépe van és egyik sem működik rendesen... O365 mert valaki azt mondta az milyen jó. Ne keressétek az értelmet. A 4,2Eurós publikus díjjal számolva 2 havi nettó díjat kérek tőlük bruttóban egész évre. Szóval kb. csinálják. Aminek az lesz a vége, hogy a nálam levő levek nem fogják érdekelni őket ( csak a dolgozókat mert nekik kellene ). Jó mondjuk egyéb más probléma is van már ott. Volt Samba alapú tartomány, de ők tettek Syno NAS-t mert az milyen jó és mindent vissza pakoltak gépekre és a NAS-ra mentenek... kézzel... talán... Van másik irodában is egy Syno de a kettőt nem kell össze kötni, hogy értelme is legyen. Mindegy... ez  már az a pont ahol kár bosszankodni is.

A bizalmi résszel egyetértek.

De a meg nem kapott levél miatti kieséssel nagyon nem. Ugyanis az e-mail a mai napig nem garantált szolgáltatás sehol, senkinél, így vagy megkapja a címzett vagy nem. Igazából nem is lehet senkit ezért felelőssé/hibássá tenni, a technológiai háttér miatt. Innentől kezdve teljesen hibás üzleti működés, ha valaki az e-mail garantált (és sokszor azonnali) megérkezésére épít pénzügyi vonzatú dolgokat. Mármint szerintem.

Láttam már projektest fejvesztve fel-alá rohangálni, mert egy bizonyos levél nem érkezett meg és ez projekt beadásának határideje után derült ki.
Oké, van olvasási meg érkeztetési igazolás. Ő abban a hiszemben volt, ha valamit elküld és nem jön vissza hibaüzenet, az célba ért. Ez valahol jogos feltételezés.
Innentől  kezdve elnyomni egy hibaüzenetet, ami nem spam, elég nagy bunkóság. Utalok itt a felhőben eltűnő levelekre :)
Ha log szerint átveszi a szerver, azért azzal történjen már valami. Ja és erre az érkeztetési igazolás sem jó. Fals biztonságot ad, hogy befogadta a szerver.

Az, hogy a számítógépet használó emberek nem tanulták meg a számítógépet használni, a szolgáltatásokat értelmezni, nem a rendszerek hiábja.

Az, hogy a manapság diplomát szerző fiatalok már ovitól számítástexchnikát tanulnak, és ennek ellenére (20 év ilyen irányú képzés után) nem tudják, hogy az e-mail nem garantált szolgáltatás, az meg az oktatás hibája.

Az, hogy rengeteg állami szerv már (olykor kizárólag) e-mail-ben kommunikál, de olyan feltételekkel, mintha az e-mail egy tértivevényes postai levél lenne, a szabályozás hibája. Mert egy átlag embernél nem bizonyító erejű bíróságon egy e-mail log adata sem és a tartalma sem,  de a hivataltól meg elfogadják, hogy "mi kikültük az e-mail-t és innentől kézbesítettnek tekinthető"...

Az meg, hogy az O365 rendszere átvesz egy levelet 2xx-el, aztán eltűnik, az pedig az MS hibája. Csak az a baj, hogy az emberek nem az MS-t hívják fel, hanem a kis szolgáltatót. Mert azzal mernek keménykedni, a naggyal nem. Én is kaptam már olyan levelet továbbítva, amit az MS rendszere küldött az O365-ös feladónak, hogy mit kell módosítani, hogy a levele célba érjen (az itt, más által említett SPF rekord nem volt módosítva az O365-be költözés során), és a feladó reklamált a címzett rendszerének üzemeltetőjénél, hogy őt nem érkeli, olda meg a címzett, hogy mégis megkapja a levelet, Ő a szuper és drága MS szogláltatást fizeti, ott tuti nincs semmi gond...

Hát, a mi spam szűrésünk pontozás alapú, és igencsak magas pontámnál dobja el a levelet (de van nyoma, hogy bejött, és eldobta magas pont miatt, tehát meg tudom mondani, mi lett a sorsa), az alatt karanténba kerül, az alatt pedig SPAM jelöléssel megkapja a user. A szinteket a user döntheti el, ha akarja (vagy használja az alapértelmezettet).

Szerintem az MS rendszere is hasonló, csak sokkal cizelláltabb, kifinomultabb, még jobban működő spam szűrés terén.

 Itt olyan esetről beszélünk, hogy átvette 2xx-el, majd a felhasználó és admin által elérhető felületek egyikén sincs semmi nyoma a levélnek. Az sem, hogy nagyon spam-nak lett minősítve, és kidobta. Az a szép, hogy ilyenre már volt példa ügyfélkörben úgy is, hogy O365-ös ügyfél küldött levelet másik, O365-ben lévő ügyfélnek.

Nade miért dobod el? Illik ott egy 500-as hibát adni, a köztes cuccokat pedig Spam folderbe pakolni és minden egyébről hibát visszaadni, ha van.

Elég sokat O365-öztünk, de olyannal nem sikerült találkozni, hogy nem volt nyoma egy levélnek. Jellemzően olyan probléma volt, hogy a Spam vagy karantén történetig nem jutott el a felhasználó (igen, ezekről 2-3 havonta ment körlevél a cégnél... nokomment).

Jah, nálam is hasonló. 5-15 között spam flag, 15 felett még csatorna lezárás előtt milter-reject: END-OF-MESSAGE from spammer.ru[xxxxxx]: 5.7.1 Blocked by SpamAssassin;

Nem merülhet fel kérdésként, hogy kinek megy vissza a hibaüzi, mert el sem engedem a kezét addig, amíg nem válaszolok neki.

Hát, a mi spam szűrésünk pontozás alapú, és igencsak magas pontámnál dobja el a levelet (de van nyoma, hogy bejött, és eldobta magas pont miatt, tehát meg tudom mondani, mi lett a sorsa), az alatt karanténba kerül, az alatt pedig SPAM jelöléssel megkapja a user. A szinteket a user döntheti el, ha akarja (vagy használja az alapértelmezettet).

Hát de baszki, akkor te is átveszed 200-as válasszal, aztán dobod el nyom nélkül a küldő szemszögéből, aztán ugyanezt a működést sérelmezed, ha más csinálja: "átvesz egy levelet 2xx-el, aztán eltűnik, az pedig az MS hibája". Elég nagy kettős mércéd van a témában.

Itt olyan esetről beszélünk, hogy átvette 2xx-el, majd a felhasználó és admin által elérhető felületek egyikén sincs semmi nyoma a levélnek. Az sem, hogy nagyon spam-nak lett minősítve, és kidobta. Az a szép, hogy ilyenre már volt példa ügyfélkörben úgy is, hogy O365-ös ügyfél küldött levelet másik, O365-ben lévő ügyfélnek.

Define "elérhető felületek", nyilván vannak esetleges hibák, de rendszerszinten és üzemszerű működés közben nem találkoztam ilyen problémákkal, pláne nem annyira tömegesen, amennyire itt majdnem katasztrófát lehetne vizionálni. A levélküldés soha nem volt és soha nem is lesz garantált adatátvitel, egyszerűen a protokoll képtelen erre és ehhez hozzájön, hogy minél több levelet kezel egy rendszer, annál több lesz számszerűen ott a "csomagvesztés" is.

https://iotguru.cloud

Azt sérelmeztem, hogy a fogadó fél nem találja nyomát, nem azt, hogy a küldő. De ez nem gyakori természetesen. De egy egekik magasztalt, mindenkiénél jobb rendszerben minimum fura.

Egyébként nem nehéz irtózat magas pontos spam-et átvenni 200-zal, mert manapság már minden elvárható feltételnek megfelelnek a spam küldők, csak a levél tartalma nagyon problémás, amit viszont az átvétel után tudonk/akarunk csak ellenőrizni. Az átvétel közbeni teljes körű ellenőrzés meg nagyon erőforrás igényes, és szerintem nem csak mi nem élünk vele emiatt. De ez változhat attól függően, mennyi gondot okoz a jövőben ez a gyakorlat.

Ez így van. De ezt oktatással kell megoldani, nem azzal, hogy mindenki hisztizik az e-mail szolgáltatóknál a nem időben, vagy nem kézbesült levelek miatt.

Egyébként én nem csak e-mail téren, hanem nagyjából minden téren, amikor pénzről van szó és határidőről, akkor mindenképp csinálok "ellenőrzést" valami közvetlen/direkt kommunikációs formában is (felhívom, hogy megkapta-e a nagyon fontos és határidős e-mail-em, stb.). Ez nem informatikai kérdés/feladat.

Valamelyik nap olyan IP-ről küldött ki levelet az MS, amelyiknek nem volt reverse neve, aztán meg szólt az ügyfél, hogy baj van! :)
Na mondom akkor oldjátok meg, aki kitalálta, hogy jó lesz átállni, az hívja fel az supportot és oldja meg én már nem tudok segíteni.

Ezek a kitiltások is!? Marketingesek jobban dolgoznak, mint az IT-sok... :/

( thedioda | 2021. 09. 27., h – 17:41 )

Szerintem nemfeltétlen rossz a shared hosting erre, legalábbis az biztos hogy olcsóbb. Viszont a Mikrovps-t biztosan messzire elkerülném az OVH-s incidens óta, annak a kimenetele meg ahogy kezelték is elég szégyenteljes volt.

Viszont a Mikrovps-t biztosan messzire elkerülném az OVH-s incidens óta, annak a kimenetele meg ahogy kezelték is elég szégyenteljes volt.

Ehhez annyit fűznék hozzá, hogy erről az OVH incidensről nem tudok ugyan, de nekem is volt egy rossz tapasztalatom a MikroVPS-el.

Egy backup szerverünk volt náluk jópár évig és teljesen elégedettek voltunk a szolgáltatással, majd egyszercsak szól a kolléga egy reggel, hogy nem érkezett meg az e-mail, hogy áttöltődtek a backupok a náluk hosztolt szerverre. Lecsekkolom a masinát és látom, hogy elérhetetlen. Mi a fene?! Felmegyek az admin felületre, ami azt mutatja, hogy rendben fut a kiszolgáló. Belépek a webes felületen keresztül a szerver konzoljára és konstatálom, hogy nincs a szervernek IP címe... Írtam nekik support ticketet, amiben küldtek nekem IP-t, gateway-t, meg netmaskot, hogy állítsam be a szerveren. A probléma csak az, hogy egy szál értesítést nem kaptunk arról, hogy a kezdetektől fogva éveken át auto konfigurált hálózatos szerveren ezentúl kézileg kell beállítani a netet, aminek hiányában elérhetetlen lesz az internet felől.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Nem mint Mikrovps írom, hanem úgy egyébként, de nem is az én bizniszem a Mikrovps. Viszont dolgozom olyan szolgáltatónak, akinél előfordulnak ilyesmi admin panelek.

A helyzet az, hogy a csoda admin felületek amikért megy a rajongás, azok általában betolják a hálózati konfigot a guest-ekbe (rebootkor is, láttam is emailt, amiben ezt roppant mód nehezményezték). Akár úgy is, hogy a hoszton mountolja a filerendszert  és odatolja, de Windows-okat hajlamosak DHCP-vel etetni. Ráadásul a felhasználók jelentős része nem pont egy kimondott sysadmin, például megtörtént, hogy OOM-mel megállt egy VM és az illető annyit írt, hogy "megállt a VPS, mi lehet". Ezzel szemben az összes ilyen admin felületet menedzserben ott a konzol elérési lehetőség, meg reboot, meg reset... Szóval azt kell mondjam, hogy adott egy jóadag igény, majd annak a nagyrészéhez alkalmazkodnak. Mi nem adminpanelezünk, meg variálunk, cserébe nem árasztanak el a VM-es ügyfelek, pedig jellemzően az átlagnál jobb gépekkel vagyunk ellátva.

Nem is az admin panel használata a gond, hanem az, hogy ügyfél igények mentén van üzemeltetve azokon a területeken is a hoszting rendszer, ahol kizárólag szakmai szempontok szerint szabadna dönteni, üzemelni. Az ügyfél majd megszokja, mert van szakmai színvonal a világon, ami alá nem megyünk. Pláne, hogy ahogy írod is, sok a laikus. Ne az egyszerű, IT-hoz nem értő emberekhez alkalmazkodjon már egy hoszting szolgáltatás...

Aztán meg szívnak a hozzá nem értő, havi 500 meg 1000 Forintot fizető kuncsafttal, akinek minden baj, mert azt sem tudja, mi az amit lát, és két naponta kell supportot nyújtani neki emiatt. Az a véleményem, hogy aki ezt az utat választja, az meg is érdemli a sorsát (üzletileg).

Muhahahaha. Sorry. Tudod mennyit harcolok az ilyenek ellen? Igaz már múlóban van. Instantazonnal alkalmazkodni kell mindenhez, a szakmai vagy akár nettó műszaki lehetőségek és igények nem szoktak számítani. Annak külön örülök amikor valamilyen csoda technikát besusognak valakinek a fülébe és utána teljesen rágyógyul. Az nem érdekes, hogy rendszeridegen, teljesen keresztbeveri az infrát és ráadásul nem is jobb érdemben csak más, sőt mint kiderült pár hete, adott pontokon konkrétan bénább az adott megoldásában. A fő érv: dehát mindenhol ez van... Igen, meg ahol tökmás van, és ahol tudják mit csinálnak...

Anno egy távoli galaxisban volt egy probálkozás, hogy XenServer és relatív komolyan, csak VPN-es konzollal stb.lehessen elérni. Teljesen életképtelen volt, mert hiába működött alapvetően jól, voltak marketing problémák és hát erre nem voltak felkészülve, hogy még esetleg kell egy VPN a konzolhoz, és hogy esetleg Windows-on telepíteni kell drivert.

Szerintem sok esetben az a gond, hogy nincs elég tőke az ilyen hosting üzlet megvalósítására.

Értem itt ez alatt azt, hogy nem a hardverre meg a beüzemelésre nincs elég, hanem az üzlet rendes felfutásáig a finanszírozásra. Emiatt jön, hogy kell olcsó csomag, hogy jöjjön gyorsan az ügyfél meg a bevétel, mert a beruházás elvitte a tőkét. Ha van idő normális ügyfélbázist építeni, akkor nem lesz gond a hozzá nem értő, de annál több gondot okozó, mindezért igen keveset fizető kuncsaftokkal.

Valamint nem helyes az a kijelentés sem szerintem, hogy valakinek ezeket az ügyfeleket is ki kell szolgálni. Nem, az ilyenek ne legyenek sehol ügyfelek. Mert aztán jön az, hogy megtörik a szarul üzemeltetett VPS-ét, és megy róla a spam-tól kezdve minden, amivel egy csomó más embernek is fejfájást okoznak, meg a VPS hoszting üzemeltetőt is megszivatják. Először tanulják meg annyira, hogy érdemben használni tudják, meg kerüljön annyiba a szolgáltatás, hogy ne vegye már meg mindenki azért, mert "ez olyan kevés, hogy ennyiért nekem is kell egy".

Normális árú VM csomagot nagyon kevesen fizetnek meg. Ahhoz egy cloud-ot kell villantani, de akkor meg legyél azonnal 101%-os uptime-mal. Nézd még a külföldi néhány EUR-os VPS-eket, azon nagyon odavertek az árazásnak sajnos. Érthetetlen, hogy hogyan jön ki, normálisan üzemeltetve. Sajnos a vevők sem nézik, hogy hú ez baziolcsó, hogy a fenében csinálják, azért óvatosan ugorjunk már bele valami 1-2 EUR /hónapos ügybe.

Mindenkit is kiszolgálnak pedig, hiába van soksok Ügyfél, nagyon kevés olyan eset van, hogy akkor köszönjük ennyi, minden fillérért megy a kűzdelem. Akkor is, ha már rég nem lenne rá szükség. Még dedikált szervert is elpasszolnak olyannak, aki azt sem érti hogy eszik vagy isszák a dolgot, bár alapvetően neki volt ilyen igénye.

Mi anno még a VPS hőskorban kezdtük, akkor jó árat lehetett kérni és olyanok voltak a vevők, akik legalább nagyjából tudják mit vesznek. Az más kérdés, hogy nem tudunk itthon annyi Ügyfelet összeszedni, illetve eltávoztak dedikált szerverre külföldre, vagy csődbe mentek..., esetleg vmi multi felvásárolta őket.

[...] hanem az, hogy ügyfél igények mentén van üzemeltetve azokon a területeken is a hoszting rendszer, ahol kizárólag szakmai szempontok szerint szabadna dönteni, üzemelni. Az ügyfél majd megszokja, mert van szakmai színvonal a világon, ami alá nem megyünk. [...]

Várjál már, itt pont azt szeretnéd, ami miatt korábban sírtál több hozzászólást is, hogy van egy szakmai színvonal és az ügyfél alkalmazkodjon hozzá...  most akkor ki kell szolgálnia a szolgáltatónak az ügyfél minden agyfasz ötletét és alkalmazkodnia kell a szolgáltatónak az ügyél minden hülyeségéhez vagy sem? El kellene dönteni, mert az nem működik, hogy VPS esetén szopassák az ügyfelet, SMTP szervernél meg az első nyikkra oldják meg.

https://iotguru.cloud

Elnézést, ha félreérthető vagyok, egyáltalán nem így értettem ezt sem meg azt sem.

SMTP szervernél én annyit várnék el, hogy az RFC-k, az általánosan elfogadott metódusok és előre közölt szabályok szerint működjön. Nem kell könnyítés, nem kell kivételezés. De ne legyen az, hogy a világ működik valahogy egységésen, ők meg tök máshogy. Van mondjuk egy SMTP szerver, minden DNS jó, DKIM, DMARC, SPF van/jó/működik, szoftverek jól konfiguráltak, mindehová máshová tökéletesen lehet levelet küldeni (pl. freemail.hu-ra is... :-). Semmilyen publikusan elérhető listán nincs fent sem a címe, sem a neve. Erre O365 elutasítja 5xx-el a csatlakozásokat. MS-nél minden általuk biztosított online ellenőrzési lehetőség szerint minden jó. Aztán support-tal két napi egyeztetés után kiderül, hogy az IP cím tiltólistán van, ami publikusan nem elérhető, sehogyan sem kérdezhető le. De nem úgy, hogy letiltották valamiért, mondjuk régebben. Hanem úgy, hogy még nem kérte senki, hogy vegyék le a tiltólistáról ezt a címet, mindig is rajta volt. Ha bárhová le lenne írva, hogy ha új szervert üzemelsz be, akkor ilyen és ilyen procedúrával hitelesítettni/engedélyeztetni kell az IP címét külön, akkor nem lenne ezzel sem gond. De első néhány nekifutásra tagadják, hogy van ilyen tiltás ("nálunk minden jónak tűnik, biztosan a szerver konfigurációjában van hiba").
Nyilván ez oda is visszavezethető lenne, ha összeesküvés-elmélet hívő lennék, hogy ha ellehetetlenítik így a kisebb szereplőket tartósan, akkor előbb-utóbb minden potenciális ügyfél náluk fog kikötni, mert a kicsinál nem űködik a levelezés stabilan, bezzeg az O365-ben szuper minden... De ez nyilván csak nettó rosszindulat tőlem, kizárólag műszaki oka lehet az ilyen eltitkolt korlátozásoknak.

De itt ugyan így mondhatnám a Netflix-et is, akikkel 2 hónapig kellett harcolni, hogy egy kisebb ISP IPv4 tartományairól engedjék a rendes fizetős ügyfeleknek, hogy nézzék a műsort... Ott is ilyen "minden tiltva default" szabály van (és náluk sincs ez dokumentálva, publikálva), aztán köröket kell futni, hogy levegyenek a listáról. Addig meg írja a kliens az internet (és Netflix) előfizetőnek, hogy "proxy-t érzékeltünk, vegye fel a kapcsolatot az internet szolgáltatójával a probléma elhárítására", és nem működik a szolgáltatás semennyire.

VPS esetén meg én azt gondolom, hogy azért ezek csak szerverek, és igenis, az igénybe vevő ügyfélnek meg kell tanulnia valamilyen szinten a szakmát, hogy használni tudja. Ne a rendszert egyszerűsítsük már a működőképesség határára a hozzá nem értő ügyfél miatt.

( djsilas | 2021. 09. 29., sze – 17:16 )

Szerkesztve: 2021. 09. 29., sze – 17:18

A tárhelyszolgáltatók 98%-a cPanelt fog adni (sajnos...), tehát attól ne ájulj el, hogy az miket tud, javarészt a "szomszédé" is kb. ugyanazt fogja tudni. Szívás mindegyikkel lehet, akár technikai, akár support jellegű, amit vagy megoldanak X időn belül, vagy nem (ez igaz MS-re, meg webhosting cégekre is). Ebben nem látok túl nagy különbséget, mindkettő tud jól vagy szarul működni, ám ha a userek nagyon rá vannak állva pl. az Outlook meg a OneDrive használatára, akkor az Exchange jobb választás lehet.

Saját részről nincs az az Isten, hogy Google/Outlook felhőbe kiadjam a céges levelezésünket. Nyilván másabb lenne a xyz@pistike.hu esetén, pont nem érdekelne, ha akár egy hétig se jönne levél, de ami fontos, az fontos. (Edit: egy bizonyos mennyiségű accountig, utána megint csak előny lehet MS-nál.)

( hzsolt94 v | 2021. 09. 30., cs – 01:33 )

Tizen valahány éve használok többtíz főre GSuiteot, közben párhuzamosan 3-4 évig többszáz főre onprem levelezést is üzemeltettem.

Azt kell hogy mondjam hogy akár milyen jól is csinálja valaki, esélyed sincs összemérhető minőségű, rendelkezésre állású, kényelmű szolgáltatást nyújtani mint a GSuite/O365. Ha ezekre van pénz és elfogadható a cloud is jogilag, akkor abszolút semmi értelme bármi másban gondolkozni.

Hogy most o365 vagy GSuite az már ízlés és helyzet kérdése. A google vitán felül megbízhatóbb, technológiailag jobb. Az o365 klasszikusabb, a Windows világba jobban beépül, a felhasználok jelentős része könnyebben megbírkózik vele.

 

Az más kérdés hogy én az o365 felhasználói felületeitől sikítófrászt kapok, de ez egyéni preferencia...