VPN er tilkoblet, men IMAP synkroniserer ikke? Sjekk disse tre lagene

Koble til kontorets VPN, åpne e-postklienten og se innboksen nekte å oppdatere mens webmail lastes normalt. Den vanlige diagnosen er at VPN sender trafikk gjennom, men blokkerer e-post, eller at passordet til kontoen er endret. Begge gjetningene hopper over strukturen i det en IMAP-klient gjør. Å nå verten, fullføre TLS, autentisere og velge en postkasse er fire forskjellige hendelser, og VPN eier bare den første.

Myten: én tilkobling betyr én innlogging

Troen er at når tunnelen står og e-postserveren svarer, er postkassen i praksis åpen. Det er den ikke. VPN gir en vei til tjenesten; den logger deg ikke inn og velger ikke en mappe. En klient kan stå på det fjerde av disse trinnene med en fullt fungerende tunnel og et gyldig passord.

Det er i dette gapet de fleste rapportene om «IMAP virker ikke over VPN» faktisk lever.

Tre IMAP-tilstander, og hvor klienter stopper

IMAP definerer en ikke-autentisert tilstand, en autentisert tilstand og en valgt tilstand, og kommandoer er bare gyldige i tilstanden som tillater dem. En tilkobling kan også starte allerede autentisert når serveren tilbyr forhåndsautentisering, så fraværet av et passordspørsmål beviser ingenting. Å velge en postkasse flytter økten fra autentisert til valgt, og først da har kommandoer som virker på meldinger et mål.

En klient som autentiserer seg riktig og deretter ikke klarer å velge den konfigurerte mappen, vil se ut som en synkroniseringsfeil mens serveren oppfører seg korrekt. Omdøpte mapper, en leverandør som mapper «innboks» annerledes, eller manglende tilgangsrettigheter ender alle her. Serverens taggede NO-svar er beviset, og det er ikke samme svar som et avvist passord.

TLS kommer før IMAP-samtalen

Med implisitt TLS på port 993 fullføres TLS-håndtrykket før noen IMAP-kommando sendes, og derfor gir et sertifikatproblem en feil som nevner tillit og ikke e-post. E-postvertens navn må valideres mot sertifikatet på samme måte som et nettvertsnavn; en tunnel som bevarer trafikken gjør ikke et ugyldig sertifikat gyldig.

Feilteksten skiller tilfellene. En tilkoblingstidsavbrudd betyr at SYN aldri ble fullført. En TLS-feil betyr at TCP-tilkoblingen virket og håndtrykket ikke. Et IMAP NO eller BAD svar betyr at begge lyktes og at protokollaget avviste noe. Noter hvilken du så før du endrer noen innstilling.

Bufret e-post er ikke bevis for noe

En e-postklient viser tidligere nedlastede meldinger uansett om den kan nå serveren i dag, så en innboks som vises forteller deg bare at lokal lagring virker. Enhver reell test må tvinge frem en serveroperasjon: oppdater en mappe, hent en melding som aldri ble lastet ned, eller send en kommando som klienten bare ville gi etter å ha valgt postkassen.

Bruk en ikke-destruktiv kontroll. Å oppdatere én mappe og lese feilloggen til kontoen er bedre enn å slette og legge til kontoen på nytt, som mest beviser at konfigurasjonsskjermen fortsatt virker.

Sending og webmail er forskjellige protokoller

Å sende e-post er innsending, ikke IMAP. Det bruker en separat tjeneste og vanligvis en separat port med sin egen TLS-modus og sin egen autentisering, så en fungerende utboks beviser ikke at IMAP-postkassen ble valgt, og en ødelagt utboks peker ikke på IMAP.

Webmail er noe annet igjen. Det kan lykkes over samme VPN fordi det er en HTTPS-økt mot en web-frontend, noe som ikke sier noe om skrivebordsklientens IMAP-vert, port eller TLS-modus.

For en overlevering, noter fire resultater hver for seg: VPN-veien, resultatet for e-postendepunktet og TLS, resultatet av kontoautentiseringen og resultatet av postkassevalget. Hold legitimasjon og meldingsinnhold utenfor notatet. Den registreringen forteller neste person om rettelsen hører til nettverket, sertifikatet, kontoen eller mappekonfigurasjonen, uten å svekke noen av beskyttelseslagene.