VPN ਰਾਹੀਂ ਭੇਜੀ ਈਮੇਲ: ਜਵਾਬ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

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

ਤਿੰਨ ਰਾਹ ਜਿਹਨਾਂ ਨੂੰ ਲੋਕ ਇੱਕ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦੇ ਹਨ

ਸਬਮਿਸ਼ਨ, ਡਿਲਿਵਰੀ ਅਤੇ ਪੜ੍ਹਨਾ ਤਿੰਨ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਦੋ ਹੀ ਤੁਹਾਡੇ ਯੰਤਰ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ।

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

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

ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਜਵਾਬ ਤੁਹਾਨੂੰ ਲੱਭੇਗਾ ਜਾਂ ਨਹੀਂ ਇਹ ਸਵਾਲ ਰਹੱਸਮਈ ਨਹੀਂ ਰਹਿੰਦਾ।

Reply-To ਖੇਤਰ ਇੱਕ ਪਤਾ ਹੈ, ਰਾਹ ਨਹੀਂ

RFC 5322 Reply-To ਨੂੰ ਉਸ ਮੇਲਬਾਕਸ ਜਾਂ ਮੇਲਬਾਕਸਾਂ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਹਨਾਂ ਨੂੰ ਜਵਾਬ ਭੇਜੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਆਮ ਡਿਫਾਲਟ From ਮੇਲਬਾਕਸ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਵਿਅਕਤੀ ਕੁਝ ਹੋਰ ਨਹੀਂ ਲਿਖਦਾ। ਦੋਵੇਂ ਹੈਡਰ ਵਿੱਚ ਬੈਠੇ ਮੇਲ ਪਤੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੂਲ ਸੁਨੇਹਾ ਭੇਜਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਦਾ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹੈ।

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

ਜੇ ਜਵਾਬ ਕਿਤੇ ਅਣਕਿਆਸੇ ਥਾਂ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਟਨਲ 'ਤੇ ਸ਼ੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ Reply-To ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਦੀਆਂ ਆਪਣੀਆਂ ਕਲਾਇੰਟ ਸੈਟਿੰਗਾਂ ਪੜ੍ਹੋ।

ਟਰੇਸ ਹੈਡਰ ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਜ ਕਰਦੇ ਹਨ

ਹਰ SMTP ਹਾਪ ਅੱਗੇ ਇੱਕ Received ਹੈਡਰ ਜੋੜਦਾ ਹੈ ਜੋ ਉਸ ਵੱਲੋਂ ਸੰਭਾਲੇ ਕਨੈਕਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਉੱਪਰ ਵਾਲਾ ਡਿਲਿਵਰੀ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਆਖਰੀ ਹਾਪ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਭੇਜੇ ਸੁਨੇਹੇ ਵਿੱਚ ਸਮੀਖਿਆ ਯੋਗ ਨੈੱਟਵਰਕ ਵੇਰਵੇ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਹ ਵੇਰਵੇ ਸਰਵਰ ਲਿਖਦੇ ਹਨ, ਤੁਸੀਂ ਨਹੀਂ ਚੁਣਦੇ। ਇਹਨਾਂ ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ ਇਹ ਪ੍ਰਦਾਤਾ ਦੀ ਸਬਮਿਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਹੈਡਰਾਂ ਨਾਲ ਉਸ ਦੇ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਸੰਭਾਲੇ ਸੁਨੇਹੇ ਤੋਂ ਉਹ ਪੜ੍ਹੋ:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

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

ਬਾਅਦ ਵਿੱਚ ਮੇਲ ਪੜ੍ਹਨਾ ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਜਵਾਬ ਖੋਲ੍ਹਦੇ ਹੋ, ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਹੁਣ ਤੁਸੀਂ ਜਿਸ ਨੈੱਟਵਰਕ 'ਤੇ ਹੋ ਉਸ ਰਾਹੀਂ ਤੁਹਾਡੀ ਮੇਲਬਾਕਸ ਸੇਵਾ ਨਾਲ ਜੁੜਦਾ ਹੈ। ਇਹ ਆਪਣੇ ਸਰੋਤ ਪਤੇ ਵਾਲਾ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਹੈ, ਕੱਲ੍ਹ ਦੇ ਸਬਮਿਸ਼ਨ ਸਾਕਟ ਦਾ ਲਗਾਤਾਰ ਹੋਣਾ ਨਹੀਂ। ਇਹ ਉਸ ਵੇਲੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਵਰਤੇ ਜਾ ਰਹੇ ਨੈੱਟਵਰਕ ਦੀ ਮੌਜੂਦਾ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।

ਰਿਮੋਟ ਸਮੱਗਰੀ ਫਿਰ ਤੀਜੀ ਚੀਜ਼ ਹੈ। ਦੂਰ ਦੀ ਤਸਵੀਰ ਲੋਡ ਕਰਨ ਵਾਲਾ ਜਾਂ ਲਿੰਕ ਫਾਲੋ ਕਰਨ ਵਾਲਾ ਮੇਲ ਕਲਾਇੰਟ ਆਪਣੀਆਂ ਮੌਜੂਦਾ ਸੈਟਿੰਗਾਂ ਹੇਠ ਵੱਖਰੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਬੇਨਤੀ ਵਿੱਚ ਸੁਨੇਹੇ ਵੱਲੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਕੋਈ ਵੀ ਪਛਾਣਕਰਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਪੁਰਾਣੇ ਪਤੇ 'ਤੇ ਆਉਣ ਵਾਲਾ SMTP ਜਵਾਬ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਮੰਨਣਾ ਅਸਲ ਖੁਲਾਸੇ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਹ ਦੱਸੇ ਬਿਨਾਂ ਸੁਨੇਹਾ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਇਹ ਖੋਲ੍ਹਿਆ ਹੈ, ਤਾਂ ਰਿਮੋਟ ਸਮੱਗਰੀ ਬੰਦ ਕਰੋ।

ਇਸਨੂੰ ਲੀਕ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

ਮੂਲ ਸੁਨੇਹੇ ਦੇ ਦ੍ਰਿਸ਼ ਅਤੇ Reply-To ਖੇਤਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ ਪਛਾਣੋ ਕਿ ਤੁਹਾਨੂੰ ਚਿੰਤਤ ਕਰਨ ਵਾਲੀਆਂ Received ਐਂਟਰੀਆਂ ਕਿਹੜੀ ਸੇਵਾ ਨੇ ਜੋੜੀਆਂ, ਅਤੇ ਇਸਦੀ ਤੁਲਨਾ ਪੁਰਾਣੇ ਫੋਰਮ ਦੇ ਜਵਾਬ ਦੀ ਥਾਂ ਪ੍ਰਦਾਤਾ ਦੇ ਮੌਜੂਦਾ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਕਰੋ।

ਅੰਤ ਵਿੱਚ, ਸਵਾਲ ਵੱਖ ਕਰੋ: ਸਬਮਿਸ਼ਨ ਸਰਵਰ ਨੇ ਕੀ ਦੇਖਿਆ, ਡਿਲਿਵਰੀ ਚੇਨ ਨੇ ਕੀ ਜੋੜਿਆ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਸੁਨੇਹਾ ਖੋਲ੍ਹਿਆ ਤਾਂ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੇ ਕੀ ਮੰਗਿਆ?

ਇਹਨਾਂ ਤਿੰਨਾਂ ਦਾ ਵੱਖਰਾ-ਵੱਖਰਾ ਜਵਾਬ ਦੇਣਾ IP ਪੰਨਾ ਜਾਂਚਣ ਨਾਲੋਂ ਵੱਧ ਕੰਮ ਹੈ, ਅਤੇ ਇਹੀ ਇੱਕੋ-ਇੱਕ ਸੰਸਕਰਣ ਹੈ ਜੋ ਤੁਹਾਡੇ ਬਚਾਅ ਯੋਗ ਸਿੱਟਾ ਦਿੰਦਾ ਹੈ। ਈਮੇਲ ਪਤੇ ਨੂੰ ਜਵਾਬ ਦੇਣਾ ਤੁਹਾਡਾ ਘਰ ਦਾ ਪਤਾ ਜ਼ਾਹਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਪੁਰਾਣੀ ਟਨਲ ਖੁੱਲ੍ਹੀ ਰੱਖਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ।