Levelezés https-en

Fórumok

Sziasztok,

A probléma az alábbi:

A levelező szerver IMAP 993, SMTP 465 vagy 587 port-on figyel.

Sok helyen ezen portok némelyike, vagy mindegyik szűrve van (pl. szállodák stb..)

Hogyan lehetne megoldani, hogy mint a GMAIL ekkor is működjön ?

Egyáltalán a GMAIL hogyan kommunikál (https ??) ?

Előre is köszönöm.

L,

Hozzászólások

Szerkesztve: 2020. 02. 24., h - 16:00

A webes felület kizárólag https-en kommunikál, szóval annak mindenképp mennie kell. Elég valószínű (90%+), hogy a hivatalos gmail app is ezt teszi. Az egyéb third-party vagy beépített appok valószínű imap vagy pop, így ezek lehetnek érintettek.

Szóval: használd a böngészőből, ha nem megy az appból.

Én használnám, de sajnos nem rólam van szó.

Nem vágom mit értesz itt az alatt hogy szűrve van...
Tiltva biztos nincsenek ezek a portok, vagy ha igen akkor ott nagy a gáz...elég sok szállodában megfordultam az elmúlt 5 évben de ilyen gondom még sosem volt.

Hát elég sok helyen van ilyen.Most pl. olyanba futottak bele, hogy elküldeni elküldte, de amíg azon a wifi-n lógott, az ott elküldött üzeneteket nem tette bele az elküldött üzenetek mappába. Olyan tapasztalat is volt, hogy Londonban a delikvensnek a szálláson 465-ön ment a küldés, egy másik helyen pedig csak 587-en (smtp szerver ugyanaz). Végén mondtam neki hogy kapcsolja ki a wifit... Újra és újra előjön ez a probléma, és persze mindig a "legfontosabb", "legsürgősebb" levelet várják, küldenék... Erre keresek valami megoldást. Elvileg Exchange esetén nem lenne probléma, de ugye az meg nem 2 fillér.

Nem az IMAP lóg a 443-on, hanem az EWS (Exchange Web Services [ezt használja pl. az Evolution Exchange connectora]), EAS (Exchange Active Sync [ezt használják a mobilok, a Windows 10-es Posta app, meg akár az újabb Outlookok is], szerver oldalon van rá néhány open source implementáció) és a MAPI az aktuális két héten használt tunnel protokoll felett (na, ezt gyakrabban váltja az MS, mint más az alsónadrágját... [ez az Outlook "natív" protokollja]).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Szerkesztve: 2020. 02. 24., h - 16:53

Huhh, nagy baj van itt a fejekben.

Kezdjuk azzal, hogy a levelezes mint olyan, nem mukodik HTTP/HTTPS felett. Az, ha valamit kiraksz a 80-as portra, attol meg nem lesz HTTP. A HTTP/IMAP/POP3/SMTP szavak ugynevezett protokollokat takarnak, ez olyasmi, mint az emberi nyelvek. Attol, mert valaki magara festi a magyar zaszlot, de kozben mondjuk brazilul hablatyol, meg nem tekintjuk tosgyokeres magyarnak. 

Olyat lehet csinalni, hogy letoltesz peldaul egy webmail klienst (peldaul a Roundcube-ot), a levelezo szerverre teszel egy (esetunkben PHP kepes) webszervert, peldaul Apache-ot, majd beallitod, hogy szolgalja ki a roundcube-ot. Ekkor a paraszt aki levelezni akar, be tud lepni egy bongeszobol a enmailszerverem.mitudomen.com -ra az emailfiokja felhasznalonevevel (email cimevel) es jelszavaval, es tud kuldeni/fogadni levelet. De ez nem HTTP feletti levelkuldes/fogadas, ezt egy weboldal csinalja, ami localhoston (tehat gyakorlatilag kozvetlenul) kommunikal a levelezoszerverrel. Nem irom le reszletesen, mert a "imap server roundcube howto" keresoszavakra negytonna tutorial fog a nyakadba zudulni, es lehet ezt meg cifrazni.

A Gmail appot azert nem szerencses idekeverni, mert webes API-kat hivogat a levelek kuldesehez es fogadasahoz. 

Szerintem, ha ennyire nem ertesz hozza, keress egy publikus mail szolgaltatot - javaslom az Office 365-ot - es intezd ott a levelezest. Nem egyszeru jora osszeloni egy levelezoszervert, meg nehezebb megoldani, hogy ne kerulhessen spamlistara a szerver, amirol az ugyfeled levelet kuld. A spamek fogadasarol, szureserol nem is beszelve. Hidd el, jot akarok neked azzal, amikor azt mondom, ne akarj hozzaertes nelkul levelezoszervert uzemeltetni. Alaphangon is nagy szopas, de kezdokent... ne rontsd el az eleted.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Huhh, nagy baj van itt a fejekben.

Kezdjük azzal, hogy köszönöm a kioktatást.

Képzeld ismerem az "úgynevezett protokollokat", sőt saját mailszervert is üzemeltetek (többek között).

Úgy látom Pély Barnásan nem jött át mit keresek, de sebaj kioktatni tudsz.

Ja kezdő sem vagyok.

Bírom ha valaki nem érti a másik mit akar, vagy nem tud megoldást, kioktat.

De azért köszönöm.

Apropó, másnak sem sikerült az outlook.hu-ra a gmail appot rágyógyítani Exchange módban, csak IMAP-al ?

Ha már... Mostanában a gmail nem jelzi az új üzeneteket, imap-os mailbox-oknál, és a leveleket is csak akkor tölti le, ha átváltok arra a mailbox-ra. Régebben ez jól működött. Tapasztalt valaki ilyet ?

Ez melyik app ? Nálam a gmail beállításai nem így néznek ki. Lényegében ugyanígy van beállítva. Ami még érdekes, hogy be van állítva 3 imap, 1 gmail, 1 exchange, 1 outlook.hu. Ebből a gmail és az exchange fiókok-ba megérkezik az üzenet, az imaposokba csak ha megnyitom. Pár hónapja tökéletesen működött, azóta semmilyen beállítás nem változott, igaz a gmail app többször is frissült. Pl. a Bluemail appnál működik rendesen, ezért gondoltam, hogy a gmail-nál változott valami.

Lehet hogy megint rosszul fogalmaztam.

Van egy normál gmail account, egy exchange account egy outlook.hu (imap), és 3 imap account ami nem gmail. A normál gmail, és exchange account-ra jönnek a levelek és értesítések. Az outlook.hu (imap) és 3 egyéb imap-os account-ra nem. Az imap-os accountok leveleit csak akkor tölti le, ha az adott mailbox-ra váltok. Android-on a GMAIL app-ról van szó. Ebben az app-ban van felvéve az összes mailbox.

A topic indítóban a következőket írod:

Hogyan lehetne megoldani, hogy mint a GMAIL ekkor is működjön ?

Egyáltalán a GMAIL hogyan kommunikál (https ??) ?

Itt meg azt, hogy a webmail nem megoldás. Ezt szerintem fejtsd ki kicsit jobban, mert így nem világos hogy mire gondoltál a topic indítóban ha nem webmailre.

Az én workaroundom az ilyen port blokkolós helyekre, hogy kifele 443-on figyel egy sslh [1] port multiplexer, ami SSH/HTTPS/OpenVPN függvényében natolja tovább a kérést a megfelelő backendjeinek. 443-on OpenVPN-re felcsattanok és onnantól elérhető a máshonnan blokkolt, pl. SMTP port.

Remélem ez segít. Lentebb krix is hasonlót javasolt, sslh-nak annyi az előnye, hogy vele nem kell a 443-at dedikáltan az OpenVPN-nek foglalni.

hrgy84 válaszát pedig szvsz enyhén túlreagáltad.

--

[1] https://github.com/yrutschle/sslh

Lehet hogy rosszul fogalmaztam meg a problémát:

A levelezést kétféleképpen érik el:

  • Notebook - Thunderbird
  • Mobil - valamelyik (leginkább a beépített) mail app.

Lehet hogy csak én vagyok ilyen szerencsétlen, de rendszeresen belefutok olyan problémába, hogy nem tudnak küldeni,fogadni, vagy mindkettő. A webmail,vpn azért nem megoldás, mert nem hozzáértő emberek használják (leginkább a management). Ha azt mondom, hogy mobilról használjanak webmail-t, vagy ha levelezni akarnak, akkor mobilon vpn-ezzenek nem biztos hogy nagy népszerűségre teszek szert. Azt sem tudják mi a mail felhasználónevük,jelszavuk. Tudom hogy nem helyes, de ez van.VPN esetén krix által említett probléma is előjöhet. Az sslh viszont izgalmasnak tűnik, meg fogom nézni.

A túlreagálásban valószínűleg igazad van, elnézést kérek mindenkitől.

7x24-ben OpenVPN-en lóg a telefonom OpenVPN Connect klienssel. Az aksi 4100 mAh, reggel 8:30 körül vettem le töltőről 100%-on, jelenleg 81%-on áll. Igaz, nem gyári ROM van rajta, hanem Resurrection Remix, bloatware mentesen (pl. közösségi appok nincsenek rajta). Az is igaz, hogy nem nyomkodom egyfolytában.

Ha jól értem ~1 órát használtad és 4%-ot merült. Az esetemben ~10 órás használat melletti 19% merülésről van szó. Félre ne érts, értem hogy aktívan használtad közben, de a következtetést nem értem. Az adatok önmagukban nem jellemzik az androidos OpenVPN klienst mivel nincs összehasonlítási alap a VPN használat nélküli merülési ütemről.

Az aksim viszont 3 éves, az iPhone XR pedig 2018 őszén jött ki ha jól látom, szóval a tiéd valamivel több mint 1 éves lehet maximum. Az aksi kor különbség valószínűleg szintén tényező.

A GMAIL APP a gmail-es szerverekkel https-en kommunikál.

A GMAIL APP más levelezőszerverekkel úgy kommunikál, ahogy beállítod; legtöbbször IMAP/SMTP lesz azokon a portokon amiket leírtál.

Ha azt szeretnéd, hogy a GMAIL APP a saját levelezőszervereddel https-en kommunikáljon, akkor kell egy gw ami ezt megoldja, pl: https://z-push.org/

Z-push-al a levelezés https/443-as porton keresztül fog menni.

Az a https az EAS-t fog jelenteni ebben az esetben, azt az Outlook meg az Androidos beépített email kliens eszi meg, Thunderbird nem. Amúgy te mégis a webmailen (meg mondjuk az EAS-on) kívül milyen lehetőséget ismersz https-en történő levélküldésre? (ha már ilyen profi vagy, hogy levelezőszervert is üzemeltetsz)

Szerkesztve: 2020. 02. 24., h - 19:27

Tipp, fellőni egy bármilyen openvpn-t (443-as portra) egy általatok menedzselt szerverre és ezen keresztül csatlakoztatni a klienseket, ha olyan helyen vannak. Pl szálloda, stb.

Persze nem 100%os megoldás, mert ha "belenéz" az XY tűzfal a 443-as kapcsolatba akkor kivághatja a francba az egészet.

Viszont az esetek többi részében menni fog bármi is, tökmind1 milyen porton kommunikál.

Én alkalmazom ezt a megoldást, van egy kis VPS VPN ami kb. erre van. Az esetek 90%ban műxik.

A helyzet komolysagara valo tekintet nelkul megjegyeznem, hogy a brazilok portugalul hablatyolnak...

hamar morgos hétfő van.

Koszi,
Gergo

> Sok helyen ezen portok némelyike, vagy mindegyik szűrve van (pl. szállodák stb..)

 

Megfordultam már jópár szállodában, panzióban, étteremben, de sehol sem tapasztaltam még, hogy tiltották volna a levelezéshez szükséges portokat a TCP/25-ön kívül...

A 25-ös portot szokták szűrni, de nem a szállodák, hanem az ISP-k.

Szerkesztve: 2020. 02. 26., sze - 07:31

Nem tudom írtak-e, de VPN lenne az egyik megoldás teljes forgalom terelésével. Openvpn sok mindenen átmegy. Rakhatod 53 vagy 443 portra. A probléma valós, kollégáim is tapasztalják konferenciákon.

ok, írták. Elolvastam a reagálást is.

tul sok mozgastered nincs. VPN. Jó dolog és egyszerű, meg ha máshogy is gondolod elsőre.

A 443-as porton VPN-t próbáltam. Tudom, hogy megint kapok érte, de nem csak világutazó szállodákban jön elő a probléma, hanem ahogy Te is mondtad, konferenciákon és uram atyám pl. nálunk Tesco, Auchan-ban sem megy a VPN 443 fölött, és persze imap-smtp sem (nem kell onnan levelezni). Azért keresek valami olyan megoldást mint a google,exchange (akinek van pénze majomra), ami https fölött megy (levelezés kell mobilra és laptopra is). Hogy árnyaljam a problémát, van pár felhasználó akinek van vpn-je (laptop-ra). Évek óta megy a harc, hogy ezt vagy azt nem tudja elérni, már megint nem működik semmi. Kérdezem a VPN be volt kapcsolva ? Válasz: nem tudom, ja az a kis izé ?, biztos, mittudomén stb... (meg kell nevelni a felhasználókat, a felső vezetést is !!). Aztán bizonygathatom hogy nem én voltam a balfék (de). Sajnos az elvek, az elmélet, és a gyakorlat sokban különbözik. Legutóbb mint írtam a legfelsőbb vezető küldött levelet (mobilról), ami ugyan elment, de a Sent mappába nem került be a levél. Kérdeztem volt valami hibaüzenet ? Válasz: ki emlékszik arra. Ha ezt megspékelem mobilra VPN-el (van ahol az sem megy).... Sajnos ez van ezzel kell főzni.

Hm, ha kiveszem a történetből a lezárt portokat, akkor nekem abból ami marat levelezőkliens-problémának (vagy levelező kliensproblémának?) tűnik az egész. Mobilon a levelezés nem tudom mennyit változott az elmúlt 2-3 évben (kb azóta nem kell ezzel szívnom), de akkor is már ilyen volt. Ugyanazon típusú készülékek között 3-4 különböző kliens volt használatban, mert teljesen változatos módon reagáltak arra, hogy nekik levelező-postafiókot kellene kezelniük. (De a szerver ugyanaz!)

A sent-be a kliens rakja el a levelet. Most, hogy ez a vékony, vagy teljesen elfogyó sávszél miatt nem ment egy publikus wifi-n?... Örüljünk annak, hogy egyáltalán elküldte. (Plö: 18MB-os csatolmány, 3 fotó. 10 percig küldi. Sent-ben nem mentette már le, sikertelen. És? De hát, hogy igazolja, hogy az ügyfélnek ő elküldte?)

Átérzem a helyzetedet, én is voltam már ilyenben, de ez egy komplex probléma, a megoldása is komplex lesz. (Ráadásul minden élethelyzetre nem is fogsz tudni megoldást találni.) Anno nálunk ami bevált: VPN, RPD kapcsolat egy Windows-os VM-re odabent, amin dolgozott a delikvens. A mobilos levelezéshez meg mobilnet. Így is sok sírás volt, hogy nem ment a VPN, de az ügyesebbje azért alkalmazkodott hozzá, meg saját workaroundja volt a problémára. (Pl 4 simkártya, más-más szolgáltatóhoz. Csak arra volt egy külön mobilja, ami neki netet szolgáltatott, amelyik jobb volt azon netezett.)

Igen, t'om :)

Meg aztán azt se felejtsük ki, hogy van amikor túllépjük az összes egyidejű imap kapcsolatok számát. (Lehet, hogy engedélyezve volt az imap, csak már teltház volt.)

Nekem az ilyen nagyon voodoo szokott lenni, hogy brózolom a leveleimet, sent-be nem ment, ebből levonom a konklúziót, hogy imap tiltva van. Nem tudom, lehet buta kérdés de olyankor nem ordítania kellene a kliensnek, hogy nem tud auth-olni a fiókhoz?

(Bevallom őszintén, hogy ilyen publikus wifi-s, tiltott portos hülyeséggel még nem találkoztam, de tömegtumultus miatti sávszélelfogyással igen. Ha túl sokan voltunk, a mobilnetem sem ment.)

HTTP-nek álcázott SSH tunnelen vidd keresztül egy külső gépen, és meg van oldva :)

arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout

Ha ennyire https a cél és az Exchange ezen megy és megoldja a problémákat, akkor tégy fel egy olyan webmail-t, ami ismeri az Exchange protokollt.

A Zimbrát nem emlegetném, mert csak a fizetősben tudja, de nem ez az egyetlen opció. pl. SoGO...

Az Exchange egyébként tud HTTP/SOAP alapon is működni, évekig használtam különböző (onprem) exchangekkel.

https://docs.microsoft.com/en-us/previous-versions/office/developer/exc…

Az Evolutionhoz van megfelelő plugin: https://github.com/GNOME/evolution-ews

arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout