Mail xira tras cambiar de VPN: resincronizar ou volver descargar?
Unha xanela de Mail atarefada tras un cambio de rede non é proba dunha nova descarga. Le o estado da conta e despois escolle entre resincronización, fallo de inicio de sesión e ruta do VPN.
Cando un cambio de rede esperta Mail e o indicador de progreso comeza a moverse, ese é o momento en que a xente conclúe que o VPN forzou unha descarga completa de novo. Normalmente non o fixo. Volver conectarse activa unha pasada de sincronización, e unha pasada de sincronización cobre o estado do buzón, as marcas e os metadatos das mensaxes moito antes de cobrir o corpo das mensaxes. A decisión útil é en cal de tres historias estás, e só o estado da propia conta pode dicircho.
Un indicador atarefado, tres historias distintas
Os tres candidatos son unha resincronización normal, un fallo de inicio de sesión ou de autenticación que volve tentar sen parar, e un problema de ruta no que Mail non pode chegar ao servidor pola rede nova de ningún xeito. De lonxe parecen iguais porque os tres animan a mesma xanela, e esixen tres accións distintas.
| What you observe | Most likely story | Where to look next |
|---|---|---|
| Brief activity that settles, mail arrives | Normal resync | Nothing to fix |
| Status says login failed | Mail account or provider authentication | The account and its provider settings |
| Status says offline or cannot contact server | Path through the new network | The VPN, proxy or filter in the way |
| Activity never settles, no new mail | Retry loop against a blocked or wrong endpoint | The exact status text and the destination |
Esa táboa é toda a decisión. Tamén explica por que «está descargando outra vez» é unha descrición da xanela e non un diagnóstico da avaría, e por que cambiar un axuste do VPN como resposta a un fallo de inicio de sesión raramente axuda.
Le o estado da conta antes de interpretar nada
Busca o indicador de estado xunto á conta afectada ou dentro da xanela de Mail, e ábreo para que a mensaxe exacta sexa visible. As indicacións de Apple para enviar e recibir separan problemas de conexión, fallos de inicio de sesión, dispoñibilidade do servizo e límites da conta, e esas catro categorías levan a catro responsables distintos. Volver escribir o contrasinal por unha mensaxe de dispoñibilidade do servizo desperdicia a mesma tarde dúas veces.
Mantén a proba estreita: unha soa conta, unha soa operación nova que non comparta nada sensible, e todo pola ruta que queres que use. Un buzón na caché pode seguir sendo totalmente visible mentres a sincronización actual falla, o que converte «vexo o meu correo» nunha proba pobre de se chega algo. Anota o texto exacto do estado antes de cambiar un axuste, porque esa frase é a única proba que terás despois. A versión que recordas cinco minutos máis tarde sempre é máis vaga ca que está na pantalla.
O Mac ten internet, pero Mail di que está sen conexión
Cando todo o demais no equipo funciona e Mail informa de que está sen conexión, a pregunta interesante é que ruta se lle pide á conexión que tome. Un axuste de servidor proxy, un filtro de rede ou un túnel que só transporta parte do tráfico poden deixar Mail nunha ruta á que o servidor non responderá. Comproba que di a configuración de proxy a nivel de sistema antes de editar a conta.
scutil --proxyDespois separa a conta da ruta. O correo web demostra que a conta funciona no provedor, pero non demostra nada sobre a configuración da app Mail nin sobre a ruta que usa a app, porque un navegador pode tomar un camiño completamente distinto cun manexo de proxy diferente. Enviar e recibir tamén poden depender de servizos distintos, así que unha operación correcta non é unha proba completa da outra.
Os duplicados son unha observación á parte
A sincronización en curso non é proba de que se creasen duplicados visibles, e os duplicados que xa existen non son proba do que fixo o VPN. Se de verdade ves copias repetidas, anótao como un achado propio e comproba o buzón no lado do servidor co provedor. Iso diche se as copias existen unha vez e se mostran dúas, ou se existen realmente dúas veces.
En calquera caso, borrar o correo local, reconstruír cada buzón ou eliminar contas é unha primeira reacción drástica a un contador de progreso. Esas accións destrúen o estado que terías necesitado para diagnosticar a pregunta orixinal, e son difíciles de reverter nun equipo que garda correo que non existe en ningún outro sitio.
Decide antes de eliminar unha conta
Se un procedemento de recuperación aprobado realmente esixe eliminar e volver engadir a conta, conserva as dúas cousas que non se poden recuperar: o traballo sen enviar e calquera correo que só exista neste equipo. Remata todo o que haxa que entregar antes de que se programe un cambio de rede e non despois, e logo desconecta cos controis habituais de quen sexa o propietario do VPN.
Por último, lembra que é a visualización de actividade. É unha observación da aplicación sobre o traballo de Mail, non unha proba de que o VPN non se poida deter nin de que o túnel sexa o responsable. A decisión, en orde, é: le o estado, clasifícao segundo a táboa, proba unha operación pola ruta prevista e só entón toca a conta.