VPN ID ਵਰਗਾ ਦਿਸਦਾ cid ਪਿਛੇਤਰ ਸਿਰਫ਼ MIME Content-ID ਹੈ

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

ਪਛਾਣਕਰਤਾ ਅਸਲ ਵਿੱਚ ਕਿਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

HTML ਮੇਲ ਘੱਟ ਹੀ ਇੱਕ ਬਲਾਕ ਵਜੋਂ ਆਉਂਦੀ ਹੈ। ਲਿਖਤ ਅਤੇ ਹਰ ਅੰਦਰੂਨੀ ਤਸਵੀਰ ਆਮ ਤੌਰ ’ਤੇ ਵੱਖਰੇ MIME ਹਿੱਸਿਆਂ ਵਜੋਂ ਸਫ਼ਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਮੁੜ ਜੋੜਦਾ ਹੈ। ਇਸ ਲਈ ਉਸਨੂੰ ਤਸਵੀਰ ਦੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਅਤੇ ਉਸ ਨਾਮ ’ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਹਵਾਲਾ ਚਾਹੀਦਾ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੀ ਜੋੜੀ ਉਦਾਹਰਨ ਲਈ ਬਣਾਈ ਗਈ ਹੈ।

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

ਹੈਡਰ ਦੀ ਲਾਈਨ ਤਸਵੀਰ ਦੇ ਹਿੱਸੇ ’ਤੇ ਹੈ; img ਤੱਤ HTML ਹਿੱਸੇ ਵਿੱਚ ਹੈ। ਕੋਣ-ਬਰੈਕਟ ਹੈਡਰ ਦੀ ਵਾਕ-ਰਚਨਾ ਦੇ ਹਿੱਸੇ ਹਨ, ਇਸ ਲਈ cid: ਹਵਾਲਾ ਆਮ ਤੌਰ ’ਤੇ ਪਛਾਣਕਰਤਾ ਉਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਲਿਖਦਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਮੁੱਲਾਂ ਵਿੱਚ ਐਸਕੇਪ ਲੋੜੀਂਦਾ ਹੈ ਉਨ੍ਹਾਂ ਦੀ ਐਨਕੋਡਿੰਗ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਜੋੜੀ ਬਦਲਣ ਦਾ ਨਿਯਮ ਨਹੀਂ, ਉਦਾਹਰਨ ਹੈ। ਅਰਥ ਦੋਵਾਂ ਸਤਰਾਂ ਦੀ ਮੇਲ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਤੋਂ ਨਹੀਂ।

@openvpn ਪਿਛੇਤਰ ਬਣਾਵਟ ਦੀ ਵਿਸਥਾਰ-ਜਾਣਕਾਰੀ ਹੈ

Content-ID ਇੱਕ ਸੁਨੇਹੇ ਅੰਦਰ ਵਿਲੱਖਣ ਹੋਣ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੇਲ ਸਾਫ਼ਟਵੇਅਰ ਅਕਸਰ @ ਅਤੇ ਡੋਮੇਨ ਜੋੜ ਕੇ ਉਸਨੂੰ ਪਤੇ ਵਰਗਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਰੂਪ ਜਨਰੇਟਰ ਦੀ ਰੀਤ ਹੈ, ਰਾਹ ਨਹੀਂ: ਹੈਡਰ ਵਿੱਚ ਕੁਝ ਵੀ ਕਲਾਇੰਟ ਨੂੰ mailer.example ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਲਈ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਸੁਨੇਹਾ ਦਿਖਾਉਣ ਵੇਲੇ ਕੋਈ ਖੋਜ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਖੇਤਰ ਖਾਤੇ ਦਾ ਨਾਮ, VPN ਵਰਤੋਂਕਾਰ ਜਾਂ VPN ਕਲਾਇੰਟ ਵੱਲੋਂ ਛੱਡੀ ਨਿਸ਼ਾਨੀ ਵੀ ਨਹੀਂ ਹੈ। ਜਿਸਨੇ ਸੁਨੇਹਾ ਜੋੜਿਆ ਉਸਨੇ ਹਿੱਸੇ ਨੂੰ ਨਾਮ ਦਿੰਦਿਆਂ ਇਹ ਸਤਰ ਚੁਣੀ।

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

ਕੱਚਾ ਸਰੋਤ ਵੇਖੋ, ਫਿਰ ਗੋਪਨੀਯਤਾ ਦੇ ਸਵਾਲ ਦਾ ਫੈਸਲਾ ਕਰੋ

ਕੱਚਾ ਸਰੋਤ ਖੋਲ੍ਹੋ ਅਤੇ ਪੂਰਾ Content-ID ਮੁੱਲ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ RFC 2392 ਮੁੱਲ ਨੂੰ ਭੇਜਣ ਵਾਲੇ ਦਾ ਹੋਸਟਨਾਮ ਜਾਂ ਖਾਤੇ ਵਰਗੀ ਸਤਰ ਲੈ ਜਾਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਉਹ ਹਰ ਥਾਂ ਲੱਭੋ ਜਿੱਥੇ ਉਹੀ ਨਾਮ ਦਿਸਦਾ ਹੈ: HTML ਵਿੱਚ cid: ਹਵਾਲਾ, ਦੂਜਾ ਹੈਡਰ, ਪਿਛਲੇ ਜਵਾਬ ਤੋਂ ਲਿਆ ਹਵਾਲਾ-ਬਲਾਕ। ਉਨ੍ਹਾਂ ਦਿੱਸਣ-ਥਾਵਾਂ ਵਿਚਕਾਰ ਮੇਲ ਹੀ ਹਿੱਸੇ ਦਾ ਮਕਸਦ ਦੱਸਦੀ ਹੈ।

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

ਦੂਰ ਦੀ ਤਸਵੀਰ ਜਾਂ ਅੰਦਰੂਨੀ ਹਿੱਸਾ: ਵੱਖਰੀ ਆਵਾਜਾਈ

ਸਰੋਤ https ਵਾਲਾ img ਤੱਤ ਅਤੇ ਸਰੋਤ cid ਵਾਲਾ img ਤੱਤ HTML ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਨੈੱਟਵਰਕ ’ਤੇ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਪਹਿਲਾ ਉਸ ਸਰੋਤ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਸੁਨੇਹਾ ਖੁੱਲ੍ਹਣ ’ਤੇ ਕਲਾਇੰਟ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਲੈਣਾ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸੁਨੇਹਾ ਪੜ੍ਹਿਆ ਗਿਆ ਅਤੇ ਕਿਹੜੇ ਪਤੇ ਤੋਂ। ਦੂਜਾ ਸੁਨੇਹੇ ਅੰਦਰ ਹੀ ਮੌਜੂਦ ਹਿੱਸੇ ਵੱਲ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਉਸਨੂੰ ਦਿਖਾਉਣ ਨਾਲ ਕਿਸੇ ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਹੁੰਦਾ।

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

ਸੁਨੇਹਾ ਭੇਜੇ ਬਿਨਾਂ ਸਬੂਤ ਸਾਂਝਾ ਕਰੋ

ਜਦੋਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਇਹ ਵੇਖਣਾ ਪਵੇ, ਪਹਿਲਾਂ ਸੋਧੋ ਅਤੇ ਇਕਸਾਰਤਾ ਨਾਲ ਸੋਧੋ। ਪਤੇ ਅਤੇ ਅਸੰਬੰਧਿਤ ਹੈਡਰ ਬਦਲੋ, ਫਿਰ Content-ID ਅਤੇ ਉਸਦਾ cid: ਹਵਾਲਾ ਨਕਲ ਵਿੱਚ ਇੱਕੋ ਹਿੱਜੇ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਬੇਮੇਲ ਇੱਕੋ-ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਬੂਤ ਨਸ਼ਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਦੱਸੋ ਕਿ ਹੈਡਰ ਕਿਹੜੇ ਹਿੱਸੇ ਦਾ ਸੀ ਅਤੇ ਕਿਹੜੀ ਲਾਈਨ ਨੇ ਉਸਦਾ ਹਵਾਲਾ ਦਿੱਤਾ। ਸਮੀਖਿਅਕ ਨੂੰ ਸੰਬੰਧ ਚਾਹੀਦਾ ਹੈ, ਸੁਨੇਹਾ ਨਹੀਂ।

ਫਿਰ ਦੋਵੇਂ ਸਿੱਟਿਆਂ ਨੂੰ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਵੱਖ ਕਰੋ: ਸੁਨੇਹੇ ਵਿੱਚ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਤਰ੍ਹਾਂ ਘੜਿਆ ਦਾਅਵਾ ਜਾਂਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸ ’ਤੇ ਬਹਿਸ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਲਾਭਦਾਇਕ ਰਿਪੋਰਟ ਇਹੀ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ।