Mac Mail, ਦੋ ਖਾਤੇ ਅਤੇ ਇੱਕ VPN ਨਿਯਮ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ
ਐਪ-ਪੱਧਰੀ ਨਿਯਮ Mail ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਉਸ ਦੇ ਕਿਸੇ ਇੱਕ ਖਾਤੇ ਦਾ ਨਹੀਂ। ਕੰਮ ਵਾਲੀ ਮੇਲ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਾਲੀ ਸੁਰੰਗ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਐਪ, ਸਰਵਰ ਅਤੇ ਸਾਈਨ-ਇਨ ਨੂੰ ਵੱਖ ਕਰੋ।
Mail ਖੁੱਲ੍ਹਦਾ ਹੈ, ਕੰਮ ਵਾਲਾ ਇਨਬਾਕਸ ਸਿੰਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਵਾਲਾ ਸਮਾਂ ਲੰਘਣ ਲੱਗਦਾ ਹੈ। ਜਾਂ ਦੋਵੇਂ ਸਿੰਕ ਹੁੰਦੇ ਹਨ, ਪਰ ਕੰਮ ਵਾਲਾ ਸਰਵਰ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸੁਰੰਗ ਚਾਲੂ ਹੈ, ਅਤੇ Mail ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕਿਹੜਾ ਖਾਤਾ ਕਿਹੜਾ ਹੈ। ਲੱਛਣ ਦਾ ਆਕਾਰ ਹਮੇਸ਼ਾ ਇੱਕੋ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਐਪ, ਦੋ ਖਾਤੇ ਅਤੇ ਇੱਕ ਨਿਯਮ ਜੋ ਐਪ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ। ਸੁਧਾਰ ਇਸ ਮੰਨਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਕਿ ਐਪ ਇੱਕ ਪਾਤਰ ਹੈ, ਸੀਮਾ ਨਹੀਂ।
ਇੱਥੇ ਤਿੰਨ ਚੋਣਕਾਰ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਉਹ ਇੱਕ-ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ। ਇੱਕ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦੀ ਹੈ, ਦੂਜਾ ਉਹ ਹੋਸਟ ਹੈ ਜਿਸ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਅਤੇ ਤੀਜਾ ਉਸ ਹੋਸਟ ਰਾਹੀਂ ਸਾਈਨ ਇਨ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਪਛਾਣ ਹੈ। ਤੁਹਾਡੀ ਨੀਤੀ ਜਿਸ ਨੂੰ ਨਾਮ ਦੇ ਸਕਦੀ ਹੈ, ਉਹੀ ਉਹ ਸੀਮਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਬਣਾ ਸਕਦੇ ਹੋ।
ਐਪ ਗਲਤ ਇਕਾਈ ਕਿਉਂ ਹੈ
Mail ਇੱਕ ਹੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਹਰ ਸੰਰਚਿਤ ਖਾਤੇ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ। ਐਪ ਵਿਰੁੱਧ ਲਿਖਿਆ ਨਿਯਮ ਉਸ ਦੇ ਸਾਰੇ ਕਨੈਕਸ਼ਨ ਫੜ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਨਿੱਜੀ ਖਾਤੇ ਨੂੰ ਕੰਮ ਵਾਲੀ ਸੁਰੰਗ ਅਤੇ ਉਸ ਦਾ ਡਿਫਾਲਟ ਰੂਟ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ। ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਫੈਸਲਾ ਹੈ, ਅਜਿਹਾ ਮਾੜਾ ਪ੍ਰਭਾਵ ਨਹੀਂ ਜਿਸ ਨੂੰ ਬਿਨਾਂ ਜਾਂਚ ਛੱਡਿਆ ਜਾ ਸਕੇ।
ਕੁਝ ਵੀ ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੋ ਕਿ ਵਰਤੋਂਕਾਰ ਅਸਲ ਵਿੱਚ ਕਿਸ ਗੱਲ ਦੀ ਸ਼ਿਕਾਇਤ ਕਰ ਰਿਹਾ ਹੈ। ਜੋ ਇਨਬਾਕਸ ਸਿੰਕ ਹੁੰਦਾ ਹੈ ਪਰ ਭੇਜ ਨਹੀਂ ਸਕਦਾ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਨਬਾਕਸ ਦੀ ਥਾਂ ਸਬਮਿਸ਼ਨ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਇੱਕ ਹੀ ਨਿੱਜੀ ਰੇਂਜ ਦੇ ਵੱਖ-ਵੱਖ ਪਤਿਆਂ 'ਤੇ ਹੋ ਸਕਦੇ ਹਨ। ਪੁੱਛੋ ਕਿ ਨਾਕਾਮੀ ਪ੍ਰਾਪਤੀ ਵਿੱਚ ਹੈ, ਭੇਜਣ ਵਿੱਚ ਹੈ ਜਾਂ ਦੋਵਾਂ ਵਿੱਚ। ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਨਿਯਮ ਨੂੰ ਕਿਹੜਾ ਅੰਤਿਮ ਬਿੰਦੂ ਢਕਣਾ ਹੈ, ਅਤੇ ਇਹ ਸਰਵਰ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨ ਵਾਲੇ ਨਾਲ ਇੱਕ ਚੱਕਰ ਬਚਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਦੋਵੇਂ ਖਾਤੇ ਵੱਖ-ਵੱਖ ਸਰਵਰ ਵਰਤਦੇ ਹਨ
ਜੇ ਕੰਮ ਵਾਲੀ ਮੇਲ ਕਾਰਪੋਰੇਟ ਰੇਂਜ ਦੇ ਅੰਦਰਲੇ ਹੋਸਟ ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ ਅਤੇ ਨਿੱਜੀ ਮੇਲ ਕਿਸੇ ਜਨਤਕ ਪ੍ਰਦਾਤਾ ਨਾਲ, ਤਾਂ ਮੰਜ਼ਿਲ-ਆਧਾਰਿਤ ਵਿਵਸਥਾ ਲੋੜ ਦੱਸ ਸਕਦੀ ਹੈ। ਇਸ ਨੂੰ ਮੇਲ ਸਰਵਰਾਂ ਦੇ ਅਸਲ ਪਤੇ, ਉਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਾਲਾ DNS, ਅਤੇ ਉਸੇ ਸੇਵਾ ਨਾਲ ਚੱਲਣ ਵਾਲੇ ਕੋਈ ਵੀ ਸਬਮਿਸ਼ਨ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਅੰਤਿਮ ਬਿੰਦੂ ਚਾਹੀਦੇ ਹਨ। ਨੀਤੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਇਕੱਠੇ ਕਰੋ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਇਨਬਾਕਸ ਢਕਣ ਵਾਲਾ ਨਿਯਮ ਪਹਿਲੀ ਭੇਜਣ 'ਤੇ ਫੇਲ੍ਹ ਹੋਵੇਗਾ।
ਪਤੇ ਵਰਤੋ, @ ਚਿੰਨ੍ਹ ਤੋਂ ਬਾਅਦ ਵਾਲਾ ਭਾਗ ਨਹੀਂ। ਮੇਲ ਪਤੇ ਵਿੱਚ ਡੋਮੇਨ ਰਾਊਟਿੰਗ ਦਾ ਬਿਆਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲੈਣ ਨਾਲ ਅਜਿਹਾ ਨਿਯਮ ਬਣਦਾ ਹੈ ਜੋ ਗਲਤ ਹੋਸਟ ਲਈ ਚੱਲਦਾ ਹੈ ਜਾਂ ਕਦੇ ਨਹੀਂ ਚੱਲਦਾ। ਅਸਲ ਅੰਤਿਮ ਬਿੰਦੂ ਖਾਤਾ ਸੈਟਿੰਗਾਂ ਜਾਂ ਪ੍ਰਬੰਧਕ ਤੋਂ ਪੱਕੇ ਕਰੋ।
ਜਦੋਂ ਦੋਵੇਂ ਖਾਤੇ ਇੱਕ ਸਰਵਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ
ਇੱਕੋ ਹੋਸਟ ਪਤੇ 'ਤੇ ਦੋ ਖਾਤੇ ਮੰਜ਼ਿਲ-ਆਧਾਰਿਤ ਚੋਣ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਰਾ ਦਿੰਦੇ ਹਨ। ਉਸ ਪਤੇ ਵੱਲ ਦਾ ਰਸਤਾ ਜੋ ਵੀ ਜੁੜਦਾ ਹੈ ਉਸ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜਾਂਚ ਨਹੀਂ ਸਕਦਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਕਿਹੜਾ ਇਨਬਾਕਸ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ। ਰਸਤਾ ਹਿਲਾਉਣ ਨਾਲ ਦੋਵਾਂ ਖਾਤਿਆਂ ਦਾ ਰਾਹ ਹਿਲਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਨਤੀਜਾ ਹੈ ਜਿਸ ਨੂੰ ਵਰਤੋਂਕਾਰ ਟਾਲਣਾ ਚਾਹੁੰਦਾ ਸੀ।
ਉਸ ਵੇਲੇ ਇਮਾਨਦਾਰ ਚੋਣਾਂ ਹਨ ਖਾਤਾ-ਸੁਚੇਤ ਨੀਤੀ ਜੇ ਪਲੇਟਫਾਰਮ ਅਤੇ ਕਲਾਇੰਟ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਕੰਮ ਵਾਲੇ ਖਾਤੇ ਲਈ ਵੱਖਰਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮੇਲ ਕਲਾਇੰਟ ਤਾਂ ਜੋ ਐਪ ਦੀ ਸੀਮਾ ਸੱਚੀ ਬਣੇ, ਜਾਂ ਇਹ ਮੰਨਣਾ ਕਿ ਦੋਵੇਂ ਖਾਤੇ ਇਕੱਠੇ ਯਾਤਰਾ ਕਰਦੇ ਹਨ। ਜਾਣ-ਬੁੱਝ ਕੇ ਇੱਕ ਚੁਣੋ ਅਤੇ ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਚੁਣਿਆ।
ਸੁਰੰਗ ਸ਼ੁਰੂ ਕਰਨਾ ਉਸ ਨੂੰ ਢਕਣਾ ਨਹੀਂ ਹੈ
Apple ਦਾ App Layer VPN ਪੇਲੋਡ MailDomains ਸੈਟਿੰਗ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ: ਸੂਚੀਬੱਧ ਡੋਮੇਨ ਸਮਰਥਿਤ ਪ੍ਰਬੰਧਿਤ ਤੈਨਾਤੀਆਂ ਵਿੱਚ Mail ਨੂੰ VPN ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ। ਇਹ ਲਾਭਦਾਇਕ ਸਮਰਥਾ ਹੈ, ਅਤੇ ਸੁਣਨ ਨਾਲੋਂ ਤੰਗ ਹੈ। ਇਹ ਸੁਰੰਗ ਉਦੋਂ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਜਦੋਂ Mail ਉਨ੍ਹਾਂ ਡੋਮੇਨਾਂ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ; ਇਹ ਹਰ ਰਸਤਾ, ਹਰ ਐਪ-ਸੰਬੰਧ ਜਾਂ ਸੁਰੰਗ ਬੰਦ ਹੋਣ ਵੇਲੇ ਕੀ ਹੁੰਦਾ ਹੈ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀ।
ਇਹ ਪ੍ਰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾ ਵੀ ਹੈ, Mail ਇੰਟਰਫੇਸ ਵਿੱਚ ਪ੍ਰਤੀ-ਖਾਤਾ ਚੈੱਕਬਾਕਸ ਨਹੀਂ। ਜੇ ਤੈਨਾਤੀ ਪ੍ਰਬੰਧਿਤ ਨਹੀਂ ਹੈ, ਤਾਂ ਸੈਟਿੰਗ ਤੁਹਾਡੇ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਅਤੇ ਕਿੰਨੀ ਵੀ ਪ੍ਰੋਫਾਈਲ ਸੋਧ ਕਰੋ ਇਹ ਉਸ ਨੂੰ ਨਹੀਂ ਬਣਾਏਗੀ।
ਕੈਸ਼ ਕੀਤੇ ਇਨਬਾਕਸ ਨਾਲ ਨਹੀਂ, ਨਵੇਂ ਸਿੰਕ ਨਾਲ ਪਰਖੋ
ਸਵੀਕ੍ਰਿਤੀ ਪਰੀਖਿਆ ਲੋਚਿਤ ਨੀਤੀ ਹੇਠ ਹਰ ਖਾਤੇ ਲਈ ਨਵਾਂ ਸਿੰਕ ਹੈ, ਨਾਲ ਹੀ ਸੁਰੱਖਿਅਤ ਖਾਤੇ ਲਈ ਅਣਉਪਲਬਧ ਸਥਿਤੀ। ਕੈਸ਼ ਕੀਤਾ ਇਨਬਾਕਸ ਅਗਲੀ ਬੇਨਤੀ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਜੁੜਿਆ VPN ਚਿੰਨ੍ਹ ਸਿਰਫ਼ ਇਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਕੋਈ ਸੁਰੰਗ ਮੌਜੂਦ ਹੈ।
ਪ੍ਰਬੰਧਕ ਨੂੰ ਕੰਮ ਵਾਲੇ ਖਾਤੇ ਦੇ ਅੰਤਿਮ ਬਿੰਦੂ ਅਤੇ ਨਿੱਜੀ ਮੇਲ ਲਈ ਚਾਹਿਆ ਵਿਵਹਾਰ ਦਿਓ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਸਮਰਥਿਤ ਖਾਤਾ-ਸੁਚੇਤ, ਡੋਮੇਨ-ਆਧਾਰਿਤ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੀਤੀ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਹਰ ਸਥਿਤੀ ਵਿੱਚ ਦੋਵਾਂ ਖਾਤਿਆਂ ਦਾ ਸਿੰਕ ਹੁੰਦਾ ਵੇਖਣਾ ਹੀ ਇਹ ਇਕੋ ਸਬੂਤ ਹੈ ਕਿ ਤੁਸੀਂ ਰਚੀ ਸੀਮਾ ਉਹੀ ਸੀਮਾ ਹੈ ਜੋ ਮਸ਼ੀਨ ਲਾਗੂ ਕਰਦੀ ਹੈ।