VPN er tilkopla, men IMAP synkroniserer ikkje? Sjekk desse tre laga

Kopla til kontoret sin VPN, opne e-postklienten og sjå innboksen nekte å oppdatere medan webmail lastar normalt. Den vanlege diagnosen er at VPN slepp trafikk gjennom, men blokkerer e-post, eller at passordet til kontoen er endra. Begge gjettingane hoppar over strukturen i det ein IMAP-klient gjer. Å nå verten, fullføre TLS, autentisere og velje ein postkasse er fire ulike hendingar, og VPN eig berre den første.

Myten: éi tilkopling betyr éi innlogging

Trua er at når tunnelen står og e-posttenaren svarar, er postkassa i praksis open. Det er ho ikkje. VPN gir ein veg til tenesta; han loggar deg ikkje inn og vel ikkje ei mappe. Ein klient kan stå på det fjerde av desse trinna med ein fullt fungerande tunnel og eit gyldig passord.

Det er i dette gapet dei fleste rapportane om «IMAP verkar ikkje over VPN» faktisk lever.

Tre IMAP-tilstandar, og kvar klientar stoppar

IMAP definerer ein ikkje-autentisert tilstand, ein autentisert tilstand og ein vald tilstand, og kommandoar er berre gyldige i tilstanden som tillèt dei. Ei tilkopling kan også starte allereie autentisert når tenaren tilbyr førehandautentisering, så fråværet av eit passordspørsmål beviser ingenting. Å velje ei postkasse flyttar økta frå autentisert til vald, og først då har kommandoar som verkar på meldingar eit mål.

Ein klient som autentiserer seg rett og deretter ikkje klarar å velje den konfigurerte mappa, vil sjå ut som ein synkroniseringsfeil medan tenaren oppfører seg korrekt. Omdøypte mapper, ein leverandør som kartlegg «innboks» annleis, eller manglande tilgangsrettar endar alle her. Den tagga NO-svara til tenaren er beviset, og det er ikkje same svar som eit avvist passord.

TLS kjem før IMAP-samtalen

Med implisitt TLS på port 993 blir TLS-handtrykket fullført før nokon IMAP-kommando blir send, og difor gir eit sertifikatproblem ein feil som nemner tillit og ikkje e-post. E-postverten sitt namn må validerast mot sertifikatet på same måte som eit nettvertnamn; ein tunnel som bevarer trafikken gjer ikkje eit ugyldig sertifikat gyldig.

Feilteksten skil tilfella. Ein tilkoplingstidsavbrot betyr at SYN aldri vart fullført. Ein TLS-feil betyr at TCP-tilkoplinga virka og handtrykket ikkje. Eit IMAP NO eller BAD svar betyr at begge lukkast og at protokollaget avviste noko. Noter kva du såg før du endrar noka innstilling.

Bufra e-post er ikkje bevis for noko

Ein e-postklient viser tidlegare nedlasta meldingar uansett om han kan nå tenaren i dag, så ein innboks som blir vist fortel deg berre at lokal lagring verkar. Kvar reell test må tvinge fram ein tenaroperasjon: oppdater ei mappe, hent ei melding som aldri vart lasta ned, eller send ein kommando som klienten berre ville gitt etter å ha valt postkassa.

Bruk ein ikkje-destruktiv kontroll. Å oppdatere éi mappe og lese feilloggen til kontoen er betre enn å slette og leggje til kontoen på nytt, som mest beviser at konfigurasjonsskjermen framleis verkar.

Sending og webmail er ulike protokollar

Å sende e-post er innsending, ikkje IMAP. Det brukar ein separat teneste og vanlegvis ein separat port med sin eigen TLS-modus og si eiga autentisering, så ein fungerande utboks beviser ikkje at IMAP-postkassa vart vald, og ein øydelagd utboks peikar ikkje på IMAP.

Webmail er noko anna igjen. Det kan lukkast over same VPN fordi det er ei HTTPS-økt mot ein web-frontend, noko som ikkje seier noko om IMAP-verten, porten eller TLS-modusen til skrivebordsklienten.

For ei overlevering, noter fire resultat kvar for seg: VPN-vegen, resultatet for e-postendepunktet og TLS, resultatet av kontoautentiseringa og resultatet av postkassevalet. Hald legitimasjon og meldingsinnhald utanfor notatet. Den registreringa fortel neste person om rettinga høyrer til nettverket, sertifikatet, kontoen eller mappekonfigurasjonen, utan å svekkje noko av vernelaga.