MS levélküldés mikor fog működni?

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

Jaj, annyira élvezem én a strandot felhőt! Nem tudom, miért ver engem az Isten az MS-sel. Most már kb. egy hete nem tudok levelet küldeni. Illetve néha sikerül, de legtöbbször nem.

Sending of the message failed.
The message could not be sent because the connection to Outgoing server (SMTP) smtp.office365.com timed out. Try again.

Ennél a Freemail jobb szolgáltatást nyújt. Az is akad néha, de egy nap múlva megjavul. 

  • 660 megtekintés

( hrgy84 | 2025. 10. 14., k – 16:15 )

GMail works like a charm. Csak mondom.

Blog | @hron84

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

via @snq-

( Czo v | 2025. 10. 14., k – 16:16 )

Ha telnettel ranezek ennek az smtp.office365.com-nak a 25-os es az 587-es portjara, akkor mind a kettonel valid SMTP bannert latok. Hol keletkezik nalad a timeout?

Lehet, bár azt gondolom, ha egyszer valamit beállítok, annak halálomig működnie kell. Továbbá néha, nagy nehezen, sokadik próbálkozásra átmegy egy-egy levél. Eddig nem tartalmaz személyes adatot:

Sending failed; The message could not be sent because the connection to Outgoing server (SMTP) smtp.office365.com timed out. Try again., exitCode=2152398862,

Egyébként 587-es port. 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Gollam | 2025. 10. 14., k – 16:45 )

Mi alapján döntöttél az MS mellett, ha egy megbízható, mindig működő levelezést szerettél volna? Tényleg érdekel, nekem csak kb. 3-4. lett volna a sorban, de akkor is kis gyomorgörccsel....

( persicsb | 2025. 10. 14., k – 16:46 )

Semmi baj nincs az Outlookkal, simán tudtam levelet küldeni ma is, meg tegnap is.

A támogatott módszer a windows-os benti gépem valami Outlook nevű sz.rral, amelyet alig kapcsolok be. Örvendenék annak, ha továbbra is menne a levelezésem Linuxon Thunderbird mail kliensen, ahogyan tette ezt eddig.

Mi változott? Miért lett time out-os? Hogyan van az, hogy egy-két levél azért nagy nehezen, sokadik nekifutásra átmegy?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Simán Evolutionből küldtem, Fedora 42.

A GNOME Online Accountok között Microsoft 365-ös account típussal van felvéve, az evolution-ews csomag telepítve. Így az Evolutionben automatikuisan megjelenik a levelezés, a GNOME Calendarban megjelenik a naptár, semmit nem kell konfigurálni külön. Ez a legtisztább, legegyszerűbb megoldás Fedorán Microsoft 365-ös leveleket küldeni. Nem is értem, hogy minek mást használni hozzá, kiváló az integráció a GNOME, az Evolution és a Microsoft 365 között. Ja, és még a céges OneDrive is látszik a Nautilusban. 

Akár céges VPN-en vagyok, akár nem, működik a levélküldés.

Van ám fejlődés a GNOME területén is a témában. Pár éve még az egész Microsoft 365 integráció szar volt, de most már nagyon kényelmes.

Azt még kutatom, hogy SharePoint mappákat hogyan tudok szinkronizálni, mivel a protokoll a háttérben ugyanaz, mennie kéne, de nem tudtam még rájönni, hogy hogyan. A Nautilus ugyan mutat egy "Shared with me" mappát, amin belül van sok minden, de azok olyan mappák, amik expliciten meg vannak osztva velem, vagy az egész céggel.

Azokat a SharePoint magas szintű site-okat nem látom, amire amúgy hozzáférésem van, akár explicit, akár valamilyen csoporttagság miatt, csak az ezeken belül lévő megosztott mappákat.

Mondjuk van egy A SharePoint site, amiben van egy A1 mappa, ami meg van velem osztva, ezt látom. Viszont van egy B SharePoint site, amihez meg hozzáférek site szinten, ennek a mappáit nem látom.

Hát ha van egy TCP 587-es portra connect timeout céges környezetben, akkor először megkérdezném a rendszergazdákat, hogy műveltek-e valamit. Akár a Microsoft 365-ben, akár a tűzfalon. 
Utána megnézném a Microsoft státusz oldalát, vagy épp az ezzel foglalkozó oldalakat, hogy van-e Outlook kiesés éppen.

Aztán megnézném a Microsoft dokumentációját az smtp.office365.com kapcsán.

Aztán megnézném más hálózatról (mobilnetről például), hogy szűkítsük, hogy hálózati hiba kinek az oldalán lehet, nálad vagy náluk.

De értem, hogy egyszerűbb a HUP-on picsogni, hogy nem megy a levelezés.
 

Közel sem biztos, mert lehet, hogy van egy L7 tűzfal a két fél között, ami háklis arra, hogy mi megy protokoll szinten. És ha neki nem tetszik valami, akkor nagyjából három féleképpen viselkedhet:
- az adott protokollnak megfelelő magas szintű hibaüzenetet fabrikálhat --> A kliensen egyértelműen megjelenik, hogy mi a gond
- küldhet egy RST csomagot, így legalább TCP szinten normálisan záródik a kapcsolat --> A kliens azonnal jelzi a hibát, bár az okát nem tudja
- vagy szarik a sessionre, és az megszakad timeouttal --> a kliens előtt ülő ember várakozik, ezzel bassza el az idejét, és csak néz, hogy most mi a tök van

Valamelyik rétegben csak feljön valami hiba, ha nem is a kliensben, de mellette, pl. egy ICMP fragmentation needed megjelenhet a dróton, csak azt ugye semmi nem dobja a felhasználó orra elé. Ilyenkor a tcpdump a legjobb barátja az embernek.

De ez tök mindegy, amíg connect timeout van, addig a Thunderbirdnél sem látszik semmi a protokollból, mert nem tud küldeni semmit sem Exchange szinten - mivel fel sem épült még a kapcsolat. Mivel még meg sem nyílik a socket.

Hello,

A net szerint ahol ez jön elő   --> exitCode=2152398862 <<-- akkor az már a STARTTLS után van (az EHLO lemegy 250 -vel),ami azt erősití hogy a TH oldalán nincs beconfolva a app token, vagy a fw nyúl bele valamiért.

De 

Persze simán lehet, hogy nincs a céges tűzfalon nincs kiengedve mindegyik IP-hez a kapcsolódás.

 

Ez elméletben igaz, a gyakorlatban meg hogy a connect timeout hiba mögött pontosan mi történt, az a gyakorlati tapasztalatok alapján közel sem egyértelmű, ezt az OS stackek eleve tudják ostobán csinálni (a linux is), meg aztán a ráépülő alkalmazások is jól félre tudják érteni.

Egyrészt oh my sweet summer child, ahogy már mondták, egy app level proxy simán tud gondot okozni.

De itt nem erről van szó, eleve másik protokoll, másik port, potenciálisan teljesen más port alapú tűzfalazással. Illetve mögötte potenciálisan teljesen más kiszolgáló infrastruktúrával.

Az csak bónusz, hogy egyébként is kevesebb fossal szokott járni, ha kliens oldalon nem smtp-t és imapot beszélsz velük

Nálunk egész sokan használják, nem szoktam rá panaszt hallani, pedig laknak itt háklis emberek.

szerk: mondjuk én az outlook pwa-t használom, szerintem lócsemegének is bőven elég lenne arra, hogy a céges cuccait tologassa, ha jól emlékszem, a privát dolgai úgyis claws-ban vannak, akkor már mindegy melyik a másik, ami emiatt fent van, az meg mégiscsak kevesebb kompatibilitási basz.

( pif73 | 2025. 10. 14., k – 17:00 )

Hello locsemege

s a klienseden nincs résztesebb log? Azt kéne tudni, hogy

(A) Meddig jutsz el amikor nem sikerül? 
(A.1) STARTTLS lemegy még? 

(B) az nem lehet hogy nálatok a proxy/firewall piszkálja a tls-t és amiatt nem megyen? 

(C) ki tudod próbálni a céges hálón kivül is?

Köszönöm a segítő szándékot, ezek szerint debugolnom kell.

Most nem tudom kipróbálni céges hálón kívül, mert a munkahelyen van a gép, ssh -CX formában érem el. El tudom hozni, de nem ma.

Hogyan tudom ezt debugolni? Wireshark? Az ilyesmivel az szokott a baj lenni, hogy nem lát bele a titkosított adatfolyamba.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

AI generated:
change the mailnews.smtp.log level in Thunderbird, go to Settings > General, click Config Editor, and then search for mailnews.smtp.loglevel. You can set the value to a number (e.g., 5 for verbose) or All to log SMTP activity. To view the logs, go to Tools > Developer Tools > Error Console

( locsemege v | 2025. 10. 14., k – 17:12 )

Szerkesztve: 2025. 10. 14., k – 17:14

További nehezítés, hogy ha jól emlékszem, konkrét kliens van regisztrálva* az MS-nél - nem röhögni, ha érteném, lehet, előrébb lennék -, szóval azt szerintem nem tudom megcsinálni, hogy a jobb debugolhatóság kedvéért itthon csinálok rá egy fiókot a Claws Mail-ben. Szívesen tenném, kényelmesebb volna, de az az érzésem, a rendszergazdáink nem örülnének annak, ha külön feladatokkal tornáztatnám őket, s ebből nem látnak pénzt.

*: talán valami application ID? Fogalmam sincs erről.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

szokik lenni un. application password (es/vagy token), amit 2fa utan tudsz generalni, ha olyan regi sz*r a kliens, hogy nem tud oauth-ot. lasd: https://support.microsoft.com/en-us/account-billing/how-to-get-and-use-…

am a timeout az biztos nem auth hiba :)