ਸਾਰੀ ਸਵੇਰ ਚੱਲ ਰਿਹਾ ਮੇਲ ਟਨਲ ਉੱਪਰ ਆਉਣ ਦੇ ਪਲ ਹੀ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਪਾਸਵਰਡ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰਨ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਪ੍ਰਵਿਰਤੀ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਸਵਾਲ ਛੱਡ ਦਿੰਦੀ ਹੈ: ਕੀ ਕਲਾਇੰਟ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਿਆ ਵੀ, ਅਤੇ ਕੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਦੇਣ ਜੋਗਾ ਅੱਗੇ ਗਿਆ? ਟਾਈਮਆਊਟ, ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਅਤੇ ਰੱਦ ਕਰਨ ਦਾ ਜਵਾਬ ਤਿੰਨ ਵੱਖਰੀਆਂ ਫੇਲਤਾਵਾਂ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਤੀਜੀ ਖਾਤੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਪੜਾਅ ਕ੍ਰਮ ਨਾਲ ਵੇਖੋ, ਫਿਰ VPN ਦੋਸ਼ ਲਾਉਣ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ, ਸਗੋਂ ਪਰਖਣ ਯੋਗ ਚੱਲ ਬਣ ਜਾਂਦਾ ਹੈ।

ਪੜਾਅ 1: ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲਤਾ ਦਾ ਵਰਗੀਕਰਨ ਕਰੋ

ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਅਸਲ ਵਿੱਚ ਜੋ ਗਲਤੀ ਪੈਦਾ ਕੀਤੀ, ਉਹ ਪੜ੍ਹੋ, ਫਿਰ ਉਸਨੂੰ ਤਿੰਨ ਟੋਕਰੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਪਾਓ। ਟਾਈਮਆਊਟ ਜਾਂ ਕਨੈਕਸ਼ਨ ਰੀਸੈਟ ਦਾ ਅਰਥ ਹੈ TCP ਪਾਥ ਫੇਲ ਹੋਇਆ; TLS ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਦਾ ਅਰਥ ਹੈ ਪਾਥ ਚੱਲਿਆ ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ; ਕੋਡ ਵਾਲਾ SMTP ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਮੇਲ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਫੈਸਲਾ ਲਿਆ। ਹਰ ਟੋਕਰੀ ਵੱਖਰੇ ਜ਼ਿੰਮੇਵਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

ਟੋਕਰੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਲਾਹੇਵੰਦ ਹੈ, ਕਿਉਂਕਿ ਸੁਧਾਰ ਇੱਕ-ਦੂਜੇ ਦੇ ਉਲਟ ਹਨ। ਜਦੋਂ ਸਰਵਰ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਤਾਂ ਟਾਈਮਆਊਟ ਵਧਾਉਣ ਨਾਲ ਕੋਈ ਲਾਭ ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਪਾਥ ਬਲੌਕ ਹੈ ਤਾਂ ਪਾਸਵਰਡ ਬਦਲਣ ਨਾਲ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਜਵਾਬ ਕੋਡ ਸੂਚੀ ਵਿੱਚ ਸਭ ਤੋਂ ਕੀਮਤੀ ਸਬੂਤ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪੂਰੀ ਆਵਾਜਾਈ ਲੜੀ ਚੱਲੀ ਅਤੇ ਸਮੱਸਿਆ ਨੀਤੀ ਜਾਂ ਪਛਾਣ ਦੀ ਹੈ। ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਟੈਕਸਟ ਸੰਭਾਲੋ, ਕਿਸੇ ਵੀ ਵਿਸਤ੍ਰਿਤ ਸਥਿਤੀ ਕੋਡ ਸਮੇਤ।

ਜੇ ਤੁਸੀਂ VPN ਤੋਂ ਬਾਹਰ ਫੇਲਤਾ ਦੁਬਾਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਇੱਥੇ ਰੁਕੋ। ਇੱਕ ਮਸ਼ੀਨ ’ਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਦਿਖਣ ਵਾਲੀ ਸਮੱਸਿਆ ਅਜੇ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

ਪੜਾਅ 2: ਐਂਡਪੌਇੰਟ ਅਤੇ TLS ਮੋਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਸੁਨੇਹਾ ਸਬਮਿਸ਼ਨ ਆਪਣੀ ਵੱਖਰੀ ਸੇਵਾ ਹੈ, ਸਰਵਰ-ਤੋਂ-ਸਰਵਰ ਰੀਲੇ ਵਾਂਗ ਇੱਕੋ ਚੀਜ਼ ਨਹੀਂ। ਸਬਮਿਸ਼ਨ ਲਈ ਪ੍ਰਦਾਤਾ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਹੋਸਟਨਾਮ, ਪੋਰਟ ਅਤੇ TLS ਮੋਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਕਿਸੇ ਹੋਰ ਮੇਲ ਸੈੱਟਅਪ ਤੋਂ ਲਿਆ ਜਾਣਿਆ ਪਰਿਚਿਤ ਪੋਰਟ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਪੋਰਟ 587 ਸਾਦੇ ਟੈਕਸਟ ਦਾ ਸਵਾਗਤ ਅਤੇ ਫਿਰ STARTTLS ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪੋਰਟ 465 ਪਹਿਲੇ ਬਾਈਟ ਤੋਂ TLS ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

ਦੋਹਾਂ ਵਿੱਚੋਂ ਗਲਤ ਜਾਂਚ ਚਲਾਉਣਾ ਉਹੀ ਗਲਤੀ ਹੈ ਜੋ ਕਲਾਇੰਟ ਦੂਜੇ ਮੋਡ ਲਈ ਸੰਰਚਿਤ ਹੋਣ ਵੇਲੇ ਕਰਦਾ ਹੈ। ਜੇ ਇੰਪਲੀਸਿਟ-TLS ਜਾਂਚ 587 ’ਤੇ ਅਟਕ ਜਾਵੇ, ਜਾਂ STARTTLS ਜਾਂਚ 465 ’ਤੇ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਪੋਰਟ ਅਤੇ ਮੋਡ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਕਰਨ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਵਿੱਚ ਮੋਡ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਸੰਰਚਨਾ ਗਲਤੀ ਨੂੰ ਬਿਨਾਂ ਜਾਂਚ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਵੰਡ ਮਿਆਰੀ ਹੋਣ ਜੋਗੀ ਪੁਰਾਣੀ ਹੈ: ਪੋਰਟ 465 ’ਤੇ ਇੰਪਲੀਸਿਟ TLS ਉਹ ਵਿਵਸਥਾ ਹੈ ਜੋ RFC 8314 ਵਿੱਚ ਦੱਸੀ ਗਈ ਹੈ।

ਇੱਥੇ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਰੁਕਾਵਟ ਨਹੀਂ, ਜਾਣਕਾਰੀ ਹੈ। ਇਹ ਸਰਵਰ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੀ ਪਛਾਣ ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਉਮੀਦ ਕੀਤੀ ਪਛਾਣ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਕਨੈਕਸ਼ਨ ਕਮਜ਼ੋਰ ਕੀਤੇ ਬਿਨਾਂ ਠੀਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਪੜਾਅ 3: ਖਾਤਾ ਬਦਲੇ ਬਿਨਾਂ ਪਾਥਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

ਐਂਡਪੌਇੰਟ, ਖਾਤਾ ਅਤੇ ਕਲਾਇੰਟ ਸੈਟਿੰਗਾਂ ਸਥਿਰ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਪਾਥ ਬਦਲੋ। ਇੱਕ ਵਾਰ ਟਨਲ ਹੇਠਾਂ ਹੋਣ ’ਤੇ ਅਤੇ ਇੱਕ ਵਾਰ ਉੱਪਰ ਹੋਣ ’ਤੇ ਭੇਜੋ, ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਵੇਖੇ ਜਾਣ ਵਾਲੇ ਪਾਥ ਅਤੇ ਸਰੋਤ ਪਤੇ ਦੀ ਨੋਟ ਲਓ। ਜੇ ਫੇਲਤਾ ਪਾਥ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਵੱਖ ਕਰ ਲਿਆ; ਜੇ ਮਸ਼ੀਨ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਤਾਂ ਨਹੀਂ।

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

ਪੂਰਾ ਟਨਲ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਵੇਖੇ ਜਾਣ ਵਾਲੇ ਸਰੋਤ ਪਤੇ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਪ੍ਰਦਾਤਾ ਅਣਜਾਣ ਸਰੋਤ ਨਾਲ ਅਣਜਾਣ ਪਾਸਵਰਡ ਨਾਲੋਂ ਸਖ਼ਤ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਇਹ ਉਨ੍ਹਾਂ ਪਾਸੇ ਦਾ ਨੀਤੀ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਗ੍ਰੇਲਿਸਟ, ਦਰ ਸੀਮਾ ਜਾਂ ਬਲਾਕ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਦਾਤਾ ਤੋਂ ਸਾਰਿਆਂ ਲਈ ਆਮੀਕਰਨ ਨਾ ਕਰੋ, ਅਤੇ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਗੁੰਮ NAT ਨਿਯਮ ਹਰ ਫੇਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। curl ਲੌਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੜਾਅ ਫੇਲ ਹੋਇਆ, ਭਾਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਪਣਾ ਲੌਗ ਨਾ ਦਿਖਾਵੇ।

ਜੇ ਟਨਲ ਨੇ ਇੰਟਰਨੈੱਟ ਟ੍ਰੈਫਿਕ ਲੈ ਜਾਣਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਰਾਊਟਿੰਗ ਅਤੇ ਇਸਦੀ ਐਗਰੈੱਸ ਨੀਤੀ ਦੋਵਾਂ ਨੂੰ ਇਸ ਮੰਜ਼ਿਲ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ਼ ਨਿੱਜੀ ਰਾਊਟ ਲੈ ਜਾਣ ਵਾਲਾ ਟਨਲ ਮੇਲ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਥਾਨਕ ਪਾਥ ’ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜੋ ਵੱਖਰੀ ਤੁਲਨਾ ਹੈ।

ਪੜਾਅ 4: ਇੱਕ ਨਿਰਦੋਸ਼ ਸੁਨੇਹਾ ਭੇਜੋ ਅਤੇ ਜਵਾਬ ਦਰਜ ਕਰੋ

ਫੇਲ ਹੋਇਆ ਪੜਾਅ ਠੀਕ ਕਰੋ, ਫਿਰ ਵੈੱਬਮੇਲ ਪੰਨੇ ਦੀ ਥਾਂ ਉਸੇ ਐਪਲੀਕੇਸ਼ਨ ਰਾਹੀਂ ਇੱਕ ਨਿਰਦੋਸ਼ ਸੁਨੇਹਾ ਸਬਮਿਟ ਕਰੋ। ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਪਣਾ ਭੇਜਣ ਵਾਲਾ ਪਾਥ ਪਰਖ ਰਹੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਇਸਦੀਆਂ ਸੰਭਾਲੀਆਂ ਸੈਟਿੰਗਾਂ ਅਤੇ TLS ਮੋਡ ਸ਼ਾਮਲ ਹਨ। ਵੈੱਬਮੇਲ ਸੈਸ਼ਨ ਇਸ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਜਵਾਬ, ਪੋਰਟ, TLS ਮੋਡ ਅਤੇ ਤੁਸੀਂ ਵਰਤਿਆ ਪਾਥ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਨਤੀਜਾ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰ ਸਕੇ। ਚੱਲਦਾ ਬਰਾਊਜ਼ਰ ਅਤੇ ਹਰਾ VPN ਆਈਕਨ ਹੋਰ ਚੀਜ਼ਾਂ ਬਾਰੇ ਨਿਰੀਖਣ ਹਨ। ਜੇ ਸੁਨੇਹਾ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਬਾਕੀ ਕੰਮ ਉਸ ਸੰਰਚਨਾ ਨੂੰ ਇਸ ਖਾਤੇ ਰਾਹੀਂ ਭੇਜਣ ਵਾਲੀ ਹਰ ਮਸ਼ੀਨ ਲਈ ਡਿਫ਼ਾਲਟ ਬਣਾਉਣਾ ਹੈ।

ਚੈੱਕਲਿਸਟ ਤਦ ਪੂਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਫੇਲ ਹੋਇਆ ਪੜਾਅ, ਕਲਾਇੰਟ ਵੱਲੋਂ ਵਰਤਿਆ ਪੋਰਟ ਅਤੇ TLS ਮੋਡ, ਸੁਨੇਹੇ ਵੱਲੋਂ ਲਿਆ ਪਾਥ ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਵਾਪਸ ਦਿੱਤਾ ਜਵਾਬ ਨਾਮ ਲੈ ਸਕਦੇ ਹੋ। ਉਹ ਚਾਰ ਤੱਥ ਇੱਕ ਧੁੰਦਲੀ ਆਊਟਬਾਕਸ ਸਮੱਸਿਆ ਨੂੰ ਅਜਿਹੇ ਬਦਲਾਅ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਜਿਸਦੀ ਕੋਈ ਸਮੀਖਿਆ ਕਰ ਸਕੇ।

ਸੰਬੰਧਿਤ ਲੇਖ