VPN är anslutet men IMAP synkroniserar inte? Kontrollera dessa tre lager

Anslut till kontorets VPN, öppna e-postklienten och se inkorgen vägra uppdateras medan webbmailen laddas normalt. Den vanliga diagnosen är att VPN släpper igenom trafik men blockerar e-post, eller att kontots lösenord har ändrats. Båda gissningarna hoppar över strukturen i det en IMAP-klient gör. Att nå värden, slutföra TLS, autentisera och välja en brevlåda är fyra olika händelser, och VPN äger bara den första.

Myten: en anslutning betyder en inloggning

Tron är att när tunneln står och e-postservern svarar är brevlådan i praktiken öppen. Det är den inte. VPN ger en väg till tjänsten; den loggar inte in dig och väljer inte en mapp. En klient kan stå vid det fjärde av dessa steg med en fullt fungerande tunnel och ett giltigt lösenord.

Det är i detta gap de flesta rapporterna om «IMAP fungerar inte över VPN» faktiskt lever.

Tre IMAP-tillstånd, och var klienter fastnar

IMAP definierar ett oautentiserat tillstånd, ett autentiserat tillstånd och ett valt tillstånd, och kommandon är bara giltiga i det tillstånd som tillåter dem. En anslutning kan också börja redan autentiserad när servern erbjuder förautentisering, så avsaknaden av en lösenordsfråga bevisar ingenting. Att välja en brevlåda flyttar sessionen från autentiserad till vald, och först då har kommandon som verkar på meddelanden ett mål.

En klient som autentiserar sig korrekt och sedan inte kan välja den konfigurerade mappen kommer att se ut som ett synkroniseringsfel medan servern beter sig korrekt. Omdöpta mappar, en leverantör som mappar «inkorg» annorlunda, eller saknade åtkomsträttigheter hamnar alla här. Serverns taggade NO-svar är beviset, och det är inte samma svar som ett avvisat lösenord.

TLS kommer före IMAP-samtalet

Med implicit TLS på port 993 slutförs TLS-handskakningen innan något IMAP-kommando skickas, vilket är varför ett certifikatproblem ger ett fel som nämner förtroende och inte e-post. E-postvärdenamnet måste valideras mot certifikatet på samma sätt som ett webbvärdenamn; en tunnel som bevarar trafiken gör inte ett ogiltigt certifikat giltigt.

Feltexten skiljer fallen. En anslutningstimeout betyder att SYN aldrig slutfördes. Ett TLS-fel betyder att TCP-anslutningen fungerade och handskakningen inte. Ett IMAP NO- eller BAD-svar betyder att båda lyckades och att protokollagret avvisade något. Anteckna vilket du såg innan du ändrar någon inställning.

Cachad e-post är inte bevis för något

En e-postklient visar tidigare nedladdade meddelanden oavsett om den kan nå servern i dag, så en inkorg som visas säger bara att den lokala lagringen fungerar. Varje verkligt test måste tvinga fram en serveroperation: uppdatera en mapp, hämta ett meddelande som aldrig laddades ned, eller skicka ett kommando som klienten bara skulle ge efter att ha valt brevlådan.

Använd en icke-destruktiv kontroll. Att uppdatera en mapp och läsa kontots fellogg är bättre än att radera och lägga till kontot igen, vilket mest bevisar att konfigurationsskärmen fortfarande fungerar.

Sändning och webbmail är olika protokoll

Att skicka e-post är inlämning, inte IMAP. Det använder en separat tjänst och vanligtvis en separat port med sitt eget TLS-läge och sin egen autentisering, så en fungerande utkorg bevisar inte att IMAP-brevlådan valdes, och en trasig utkorg pekar inte ut IMAP.

Webbmail är återigen annorlunda. Det kan lyckas över samma VPN eftersom det är en HTTPS-session mot en webbfrontend, vilket inte säger något om skrivbordsklientens IMAP-värd, port eller TLS-läge.

För en överlämning, anteckna fyra resultat var för sig: VPN-vägen, resultatet för e-poständpunkten och TLS, resultatet av kontoautentiseringen och resultatet av brevlådevalet. Håll inloggningsuppgifter och meddelandeinnehåll utanför anteckningen. Den registreringen berättar för nästa person om rättelsen hör till nätverket, certifikatet, kontot eller mappkonfigurationen, utan att försvaga något av skyddslagren.