사무실 VPN에 연결하고 메일 클라이언트를 열면 웹메일은 정상적으로 로드되는데 받은편지함은 새로 고치기를 거부합니다. 흔한 진단은 VPN이 트래픽은 통과시키지만 메일을 차단한다거나, 계정 비밀번호가 바뀌었다는 것입니다. 두 추측 모두 IMAP 클라이언트가 하는 일의 구조를 건너뜁니다. 호스트에 도달하는 것, TLS를 마치는 것, 인증하는 것, 메일함을 선택하는 것은 네 가지 다른 사건이며, VPN은 첫 번째만 담당합니다.

통념: 하나의 연결은 하나의 로그인

터널이 서고 메일 서버가 응답하면 메일함이 사실상 열려 있다는 것이 통념입니다. 그렇지 않습니다. VPN은 서비스로 가는 경로를 제공할 뿐 로그인시키지 않고 폴더를 선택하지도 않습니다. 클라이언트는 완벽하게 작동하는 터널과 유효한 비밀번호를 갖고도 그 네 번째 단계에 머물 수 있습니다.

«VPN에서 IMAP이 깨졌다»는 보고의 대부분은 실제로 이 틈에 있습니다.

세 가지 IMAP 상태와 클라이언트가 멈추는 곳

IMAP은 인증되지 않은 상태, 인증된 상태, 선택된 상태를 정의하며 명령은 그것을 허용하는 상태에서만 유효합니다. 서버가 사전 인증을 제공하면 연결이 이미 인증된 채로 시작될 수도 있으므로 비밀번호 입력 요구가 없다고 해서 아무것도 증명되지 않습니다. 메일함을 선택하면 세션이 인증됨에서 선택됨으로 이동하고, 그때에야 메시지에 작용하는 명령에 대상이 생깁니다.

인증에 성공한 뒤 구성된 폴더를 선택하지 못하는 클라이언트는 서버가 올바르게 동작해도 동기화 실패처럼 보입니다. 이름이 바뀐 폴더, «받은편지함»을 다르게 매핑하는 공급자, 빠진 접근 권한이 모두 여기에 해당합니다. 서버의 태그된 NO 응답이 증거이며, 거부된 비밀번호에 대한 응답과는 다릅니다.

TLS는 IMAP 대화보다 먼저 온다

포트 993의 암시적 TLS에서는 IMAP 명령이 전송되기 전에 TLS 핸드셰이크가 완료되므로, 인증서 문제는 메일이 아니라 신뢰를 언급하는 오류를 냅니다. 메일 호스트 이름은 인증서에 대해 검증되어야 합니다 웹 호스트 이름과 마찬가지로; 트래픽을 보존하는 터널이 유효하지 않은 인증서를 유효하게 만들지는 않습니다.

오류 텍스트는 경우를 구분합니다. 연결 시간 초과는 SYN이 끝나지 않았다는 뜻입니다. TLS 오류는 TCP 연결은 작동했고 핸드셰이크는 실패했다는 뜻입니다. IMAP NO 또는 BAD 응답은 둘 다 성공했고 프로토콜 계층이 무언가를 거부했다는 뜻입니다. 설정을 바꾸기 전에 어느 것을 보았는지 기록하세요.

캐시된 메일은 아무것도 증명하지 않는다

메일 클라이언트는 오늘 서버에 도달할 수 있는지와 무관하게 이전에 내려받은 메시지를 표시하므로, 받은편지함이 보인다는 것은 로컬 저장소가 작동한다는 것만 알려 줍니다. 실제 테스트는 서버 작업을 강제해야 합니다: 폴더를 새로 고치거나, 한 번도 내려받지 않은 메시지를 가져오거나, 메일함을 선택한 뒤에만 클라이언트가 내보내는 명령을 보내야 합니다.

비파괴 점검을 사용하세요. 폴더 하나를 새로 고치고 계정의 오류 로그를 읽는 것이, 주로 구성 화면이 아직 작동한다는 것만 증명하는 계정 삭제·재추가보다 낫습니다.

보내기와 웹메일은 다른 프로토콜

메일 보내기는 제출이며 IMAP이 아닙니다. 별도 서비스와 보통 별도 포트를 사용하며 자체 TLS 모드와 자체 인증을 가지므로, 보내기함이 작동해도 IMAP 메일함이 선택되었다는 증거가 되지 않고, 보내기함이 고장 나도 IMAP의 잘못이 아닙니다.

웹메일은 또 다릅니다. 같은 VPN에서 성공할 수 있는데, 웹 프런트엔드에 대한 HTTPS 세션이기 때문이며, 데스크톱 클라이언트의 IMAP 호스트, 포트, TLS 모드에 대해서는 아무것도 말해 주지 않습니다.

인수인계를 위해 네 가지 결과를 따로 기록하세요: VPN 경로, 메일 엔드포인트와 TLS 결과, 계정 인증 결과, 메일함 선택 결과입니다. 자격 증명과 메시지 내용은 메모에 남기지 마세요. 그 기록은 수정이 네트워크, 인증서, 계정, 폴더 구성 중 어디에 속하는지 다음 사람에게 알려 주며, 두 보호 계층을 모두 약화시키지 않습니다.

관련 글