VPN konektita sed IMAP ne sinkronigas? Kontrolu ĉi tiujn tri tavolojn

Konektiĝu al la oficeja VPN, malfermu la retpoŝtan klienton kaj observu, ke la enirkesto rifuzas refreŝiĝi dum retpoŝto en la retumilo ŝarĝiĝas normale. La kutima diagnozo estas, ke la VPN trapasigas trafikon sed blokas poŝton, aŭ ke la pasvorto de la konto ŝanĝiĝis. Ambaŭ konjektoj preterlasas la strukturon de tio, kion faras IMAP-kliento. Atingi la gastiganton, fini TLS, aŭtentikiĝi kaj elekti poŝtkeston estas kvar malsamaj eventoj, kaj la VPN posedas nur la unuan.

La mito: unu konekto signifas unu ensaluton

La kredo estas, ke la poŝtkesto estas praktike malfermita tuj kiam la tunelo staras kaj la poŝtservilo respondas. Ĝi ne estas. La VPN provizas vojon al la servo; ĝi ne ensalutas vin kaj ne elektas dosierujon. Kliento povas resti ĉe la kvara el tiuj paŝoj kun perfekte funkcianta tunelo kaj valida pasvorto.

Ĝuste en tiu breĉo vivas la plej multaj raportoj «IMAP ne funkcias tra VPN».

Tri IMAP-statoj kaj kie klientoj haltas

IMAP difinas neaŭtentikitan staton, aŭtentikitan staton kaj elektitan staton, kaj komandoj validas nur en la stato, kiu permesas ilin. Konekto ankaŭ povas komenciĝi jam aŭtentikita kiam la servilo proponas antaŭan aŭtentikigon, do la manko de pasvorta invito pruvas nenion. Elekti poŝtkeston movas la seancon de aŭtentikita al elektita, kaj nur tiam komandoj, kiuj agas sur mesaĝojn, havas celon.

Kliento, kiu sukcese aŭtentikiĝas kaj poste malsukcesas elekti la agordan dosierujon, aspektos kiel sinkroniga fiasko dum la servilo kondutas ĝuste. Renomitaj dosierujoj, provizanto, kiu mapas «enirkeston» alimaniere, aŭ mankantaj alirrajtoj ĉiuj finiĝas ĉi tie. La etikedita NO-respondo de la servilo estas la pruvo, kaj ĝi ne estas la sama respondo kiel malakceptita pasvorto.

TLS venas antaŭ la IMAP-interparolo

Ĉe implicita TLS sur pordo 993, la TLS-manpremo finiĝas antaŭ ol iu ajn IMAP-komando estas sendita, kio klarigas, kial certifikata problemo produktas eraron, kiu mencias fidon anstataŭ poŝton. La poŝta gastigantnomo devas validiĝi kontraŭ la certifikato same kiel reta gastigantnomo; tunelo, kiu konservas trafikon, ne faras nevalidan certifikaton valida.

La erarteksto apartigas la kazojn. Konekta tempolimo signifas, ke la SYN neniam finiĝis. TLS-eraro signifas, ke la TCP-konekto funkciis kaj la manpremo ne. IMAP NO aŭ BAD respondo signifas, ke ambaŭ sukcesis kaj la protokola tavolo malakceptis ion. Notu, kiun vi vidis, antaŭ ol ŝanĝi ajnan agordon.

Kaŝmemorita poŝto ne pruvas ion

Retpoŝta kliento montras antaŭe elŝutitajn mesaĝojn sendepende de tio, ĉu ĝi povas atingi la servilon hodiaŭ, do montrata enirkesto diras al vi nur, ke loka konservado funkcias. Ĉiu reala testo devas devigi servilan operacion: refreŝigu dosierujon, elŝutu mesaĝon, kiu neniam estis elŝutita, aŭ sendu komandon, kiun la kliento eldonus nur post elekti la poŝtkeston.

Uzu nedetruan kontrolon. Refreŝigi unu dosierujon kaj legi la erarlogaron de la konto estas pli bone ol forigi kaj re-aldoni la konton, kio ĉefe pruvas, ke la agorda ekrano ankoraŭ funkcias.

Sendo kaj retpoŝto estas malsamaj protokoloj

Sendi poŝton estas submeto, ne IMAP. Ĝi uzas apartan servon kaj kutime apartan pordon kun propra TLS-reĝimo kaj propra aŭtentikigo, do funkcianta elirujo ne pruvas, ke la IMAP-poŝtkesto estis elektita, kaj rompita elirujo ne kulpigas IMAP.

Retpoŝto en la retumilo estas denove malsama. Ĝi povas sukcesi tra la sama VPN ĉar ĝi estas HTTPS-seanco al reta fasado, kio diras nenion pri la IMAP-gastiganto, pordo aŭ TLS-reĝimo de la labortabla kliento.

Por transdono, notu kvar rezultojn aparte: la VPN-vojon, la rezulton de la poŝta finpunkto kaj TLS, la rezulton de konto-aŭtentikigo kaj la rezulton de poŝtkesta elekto. Tenu akreditaĵojn kaj mesaĝan enhavon ekster la noto. Tiu registro diras al la sekva persono, ĉu la riparo apartenas al la reto, la certifikato, la konto aŭ la dosieruja agordo, sen malfortigi iun ajn protektan tavolon.