VPN बदलल्यानंतर Mail फिरत राहते: पुन्हा सिंक करायचे की पुन्हा डाउनलोड करायचे?

जेव्हा नेटवर्कमधील बदल Mail ला जागवतो आणि प्रगती निर्देशक हलू लागतो, तेव्हाच लोक निष्कर्ष काढतात की VPN ने पूर्ण पुन्हा डाउनलोड लादले आहे। सहसा असे झालेले नसते। पुन्हा कनेक्ट होणे सिंक्रोनाइझेशन फेरी सुरू करते, आणि सिंक्रोनाइझेशन फेरी संदेशांच्या मुख्य भागापर्यंत पोहोचण्याच्या खूप आधी मेलबॉक्सची स्थिती, फ्लॅग आणि संदेश मेटाडेटा व्यापते। उपयुक्त निर्णय हा आहे की तुम्ही तीनपैकी कोणत्या कथेत आहात, आणि ते फक्त खात्याची स्वतःची स्थितीच सांगू शकते।

एक व्यस्त निर्देशक, तीन वेगळ्या कथा

तीन संभाव्यता म्हणजे सामान्य पुन्हा सिंक, सतत प्रयत्न करणारी लॉगिन किंवा प्रमाणीकरण त्रुटी, आणि नवीन नेटवर्कमधून Mail सर्व्हरपर्यंत पोहोचूच शकत नाही अशी मार्ग समस्या। दूरून त्या सारख्याच दिसतात, कारण तिन्ही एकच विंडो हलवतात, आणि तिन्हींसाठी वेगळी पावले लागतात।

तीच तक्ता संपूर्ण निर्णय आहे। «ते पुन्हा डाउनलोड करत आहे» हे विंडोचे वर्णन आहे, दोषाचे निदान नाही, आणि लॉगिन त्रुटीला उत्तर म्हणून VPN सेटिंग बदलणे का क्वचित मदत करते, हेही ती स्पष्ट करते।

काहीही अर्थ लावण्यापूर्वी खात्याची स्थिती वाचा

प्रभावित खात्याजवळ किंवा Mail विंडोमध्ये स्थिती निर्देशक शोधा आणि तो उघडा जेणेकरून नेमका संदेश दिसेल। पाठवणे व प्राप्त करणे याबद्दलचे Apple चे मार्गदर्शन कनेक्शन अडचणी, लॉगिन अपयश, सेवेची उपलब्धता आणि खाते मर्यादा वेगळ्या करते, आणि या चार श्रेणी चार वेगळ्या जबाबदारांकडे नेतात। सेवेच्या उपलब्धतेबद्दलच्या संदेशासाठी पासवर्ड पुन्हा टाइप करणे तीच दुपार दोन वेळा वाया घालवते।

चाचणी अरुंद ठेवा: एक खाते, संवेदनशील काहीही सामायिक न करणारी एक नवीन क्रिया, आणि सर्व काही तुम्हाला वापरायच्या मार्गाने। कॅशे केलेले इनबॉक्स सध्याचे सिंक अपयशी होत असतानाही पूर्ण दिसत राहू शकते, ज्यामुळे «मला माझे मेल दिसते» हे काही येत आहे का याची कमकुवत चाचणी बनते। सेटिंग बदलण्यापूर्वी स्थितीचा नेमका मजकूर लिहून ठेवा, कारण तेच वाक्य पुढे तुमच्याकडे राहणारा एकमेव पुरावा असेल। पाच मिनिटांनंतर आठवणारी आवृत्ती नेहमी स्क्रीनवरील आवृत्तीपेक्षा अस्पष्ट असते।

Mac मध्ये इंटरनेट आहे, पण Mail ऑफलाइन आहे असे सांगते

जेव्हा मशीनवरील बाकी सर्व काही चालते आणि Mail ऑफलाइन असल्याचे नोंदवते, मनोरंजक प्रश्न हा आहे की कनेक्शनला कोणत्या मार्गाने जायचे सांगितले जात आहे। प्रॉक्सी सेटिंग, नेटवर्क फिल्टर किंवा काही रहदारीच वाहून नेणारा टनेल Mail ला सर्व्हर उत्तर देणार नाही अशा मार्गावर ठेवू शकतात। खाते संपादित करण्यापूर्वी सिस्टम-स्तरीय प्रॉक्सी संरचना काय सांगते ते तपासा।

scutil --proxy

मग खाते मार्गापासून वेगळे करा। वेबमेल हे सिद्ध करते की खाते प्रदात्याकडे चालते, पण Mail ॲपची संरचना किंवा ॲप वापरत असलेल्या मार्गाबद्दल ते काहीही सिद्ध करत नाही, कारण ब्राउझर वेगळ्या प्रॉक्सी हाताळणीसह पूर्णपणे वेगळा मार्ग घेऊ शकतो। पाठवणे व प्राप्त करणे वेगळ्या सेवांवरही अवलंबून असू शकते, म्हणून एक यशस्वी क्रिया दुसऱ्याची संपूर्ण चाचणी नाही।

डुप्लिकेट हे वेगळे निरीक्षण आहे

चालू असलेले सिंक्रोनाइझेशन दिसणारे डुप्लिकेट तयार झाल्याचा पुरावा नाही, आणि आधीच अस्तित्वात असलेले डुप्लिकेट VPN ने काय केले याचा पुरावा नाही। तुम्हाला खरोखर पुनरावृत्ती झालेल्या प्रती दिसत असतील, तर ते स्वतंत्र शोध म्हणून नोंदवा आणि प्रदात्यासोबत सर्व्हरच्या बाजूला मेलबॉक्स तपासा। यामुळे प्रती एकदा आहेत आणि दोन वेळा दाखवल्या जातात, की खरोखर दोन वेळा आहेत, हे कळेल।

कोणत्याही प्रकारे, स्थानिक मेल हटवणे, प्रत्येक मेलबॉक्स पुन्हा बांधणे किंवा खाती काढणे ही प्रगती काउंटरवरची तीव्र पहिली प्रतिक्रिया आहे। या क्रिया मूळ प्रश्नाचे निदान करण्यासाठी लागणारी स्थिती नष्ट करतात, आणि ज्या मशीनमध्ये दुसरीकडे कुठेही नसलेले मेल आहे तिथे त्या उलटवणे कठीण आहे।

खाते काढण्यापूर्वी निर्णय घ्या

जर मंजूर पुनर्प्राप्ती प्रक्रियेसाठी खरेच खाते काढून पुन्हा जोडणे आवश्यक असेल, तर पुन्हा मिळू शकत नाहीत अशा दोन गोष्टी जपून ठेवा: न पाठवलेले काम आणि फक्त याच मशीनवर असलेले कोणतेही मेल। नेटवर्क बदल नियोजित होण्यापूर्वीच, नंतर नाही, सादर करायचे सर्व पूर्ण करा, नंतर VPN च्या मालकाच्या नेहमीच्या नियंत्रणांद्वारे डिस्कनेक्ट करा।

शेवटी, क्रियाकलाप प्रदर्शन काय आहे ते लक्षात ठेवा। ते Mail च्या स्वतःच्या कामाबद्दल ॲपचे निरीक्षण आहे, VPN थांबवता येत नाही किंवा बोगदाच जबाबदार आहे याचा पुरावा नाही। निर्णय, क्रमाने, असा आहे: स्थिती वाचा, तक्त्याशी तुलना करून वर्गीकृत करा, इच्छित मार्गाने एक क्रिया तपासा, आणि त्यानंतरच खात्याला हात लावा।