ਪਤਾ ਕਰੋ ਕਿ ਕਿਵੇਂ DSN SMTP ਈਮੇਲ ਤੇ ਡਿਲਿਵਰੀ ਸਥਿਤੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਉਦੇਸ਼ ਹੈ
ਕੀ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਈ-ਮੇਲ ਭੇਜੀ ਹੈ?
ਇੱਥੋਂ ਤੱਕ ਕਿ SMTP ਪ੍ਰੋਟੋਕੋਲ ਤੇ ਇੱਕ ਸੰਖੇਪ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵੀ ਤੁਹਾਨੂੰ ਇਹ ਨੋਟਿਸ ਮਿਲੇਗਾ ਕਿ ਹੋਲੋ ਦੇ ਇਲਾਵਾ, ਈਐਚਓ ਵੀ ਹੈ, ਜੋ ਐਕਸਟੈਂਡਡ SMTP ਸਰਵਰ ਨੂੰ ਅਸਲੀ ਸਟੈਂਡਰਡ ਤੋਂ ਪਰੇ ਆਪਣੀ ਸਮਰੱਥਾਵਾਂ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦਿੰਦਾ ਹੈ. ਇਹਨਾਂ ਵਿੱਚੋਂ ਇਕ DSN ਹੈ DSN? ਕੀ ਡੀਐਨਏ ਅਤੇ ਡੀਡੀਟੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ?
ਇਹ ਦਲੀਲ ਦੇਣ ਲਈ ਕਿ ਈ-ਮੇਲ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ, ਕਿ " ... ਆਪਣੇ ਸਰਵਰ ਨੂੰ ਬਿਹਤਰ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ , ਇਹ ਮੇਰੇ ਮੇਲ ਖਾਂਦੇ ਹਨ ... " ਅਸਧਾਰਨ ਨਹੀਂ ਹੈ. ਮੈਂ ਇਹ ਖੁਦ ਕਰਦਾ ਹਾਂ ਫਿਰ ਵੀ, ਇਹਨਾਂ ਸ਼ੰਕਿਆਂ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਦੇ ਬਹੁਤ ਜਿਆਦਾ ਕਾਰਨ ਨਹੀਂ ਹਨ.
ਡਿਲਿਵਰੀ ਐਸ ਟੈਟੂ ਐਨ ਓਟੀਫਿਕੇਸ਼ਨ ਆਰਸੀਐਫ 821 ਤੋਂ (1982 ਤੋਂ) ਆਲੇ-ਦੁਆਲੇ ਹੈ. ਜਿਵੇਂ ਹੀ SMTP ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਡੇਟਾ ਹਿੱਸਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਸਰਵਰ ਨੇ ਡਿਲੀਵਰੀ ਲਈ ਈਮੇਲ ਸਵੀਕਾਰ ਕਰ ਲਈ ਹੈ, ਇਸ ਲਈ ਇਸਦਾ ਜ਼ਿੰਮੇਵਾਰ ਹੈ. ਜੇ, ਕਿਸੇ ਵੀ ਕਾਰਨ ਕਰਕੇ, ਇਹ ਪ੍ਰਾਪਤਕਰਤਾ ਦੁਆਰਾ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਨੂੰ ਅਸਲ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਗਲਤੀ ਦੀ ਸੂਚਨਾ ਨਾਲ ਵਾਪਸ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਕੁਝ ਅਸਪਸ਼ਟ ਈਮੇਲ ਹੋ ਗਏ .
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਪੁਰਾਣੇ ਸੰਮੇਲਨ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੋਈ ਗਲਤੀ ਸੁਨੇਹਾ ਮਿਲਿਆ ਹੈ ਜਾਂ ਤੁਹਾਨੂੰ ਕੁਝ ਵੀ ਨਹੀਂ ਮਿਲਿਆ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਜਾਣਦੇ: ਈ ਮੇਲ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ. ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਅਸ਼ੁੱਧੀ ਸੰਦੇਸ਼ ਕਿਸੇ ਵੀ ਗਲਤੀ ਸੁਨੇਹੇ ਦੇ ਤੌਰ ਤੇ ਸਹਾਇਕ ਨਹੀਂ ਸਨ. ਈ-ਮੇਲ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਬਣਾਉਣ ਨਾਲ ਇਹ ਹੁਣ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਹੈ (ਜਿਵੇਂ ਕਿ ਇਹ ਪਹਿਲਾਂ ਸੀ).
SMTP ਨੂੰ DSN ਐਕਸਟੈਂਸ਼ਨਾਂ
RFC 1891 SMTP ਪ੍ਰੋਟੋਕਾਲ ਨੂੰ ਕੁਝ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੀ ਤਜਵੀਜ਼ ਕਰਦਾ ਹੈ ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਵੱਧ ਭਰੋਸੇਮੰਦ ਅਤੇ ਹੋਰ ਵਰਤੋਂ ਯੋਗ DSN ਸਿਸਟਮ ਹੋ ਸਕਦਾ ਹੈ. ਇਹ MAIL ਅਤੇ RCPT ਕਮਾਂਡਾਂ ਦੇ ਐਕਸਟੈਨਸ਼ਨਾਂ ਦਾ ਸੈੱਟ ਹੈ (ਜੇ ਇਹ ਤੁਹਾਡੇ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ, ਪੜ੍ਹੋ ਕਿ SMTP ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਇੱਥੇ ਵਾਪਸ ਆਉਂਦੀ ਹੈ.).
ਕੋਈ ਏਐਚਓ, ਕੋਈ ਮਜ਼ੇਦਾਰ ਨਹੀਂ
ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਪਏਗਾ ਕਿ ਸਰਵਰ DSN ਨੂੰ ਸਮਰਥਤ ਕਰੇ. ਇਸ ਲਈ, ਸਾਨੂੰ ਉਸਨੂੰ ਈ.ਐਚ.ਓ.ਓ. ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਧਿਆਨ ਨਾਲ ਸੁਣੋ. ਜੇਕਰ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਸੂਚੀ ਵਿੱਚ DSN somewher ਨਾਲ ਜਵਾਬ ਦੇਵੇ ਤਾਂ ਅਸੀਂ ਇਹ ਮੰਨ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਸਾਡੀ ਬੇਨਤੀਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ. ਜੇ ਨਹੀਂ, ਤਾਂ ਨਹੀਂ: ਅਸੀਂ ਕਿਸੇ ਹੋਰ ਸਰਵਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ ਜਾਂ DSN ਤੋਂ ਬਿਨਾਂ ਈਮੇਲ ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹਾਂ. ਉਦਾਹਰਨ ਲਈ (ਮੇਰੀ ਇਨਪੁਟ ਨੀਲੀ ਹੈ, ਸਰਵਰ ਦਾ ਆਉਟਪੁਟ ਕਾਲੇ):
220 ਲਾਰੋਜ਼. ਮੈਗਨੈਟ. ESMTP ਸੇਡੇਮੇਲ 8.8.6 / 8.8.6; ਸੁਨ, 24 ਅਗਸਤ 1997 18:23:22 +0200
EHLO ਲੋਕਲਹੋਸਟ
250- ਲਾਰੇਸ.ਮੈਗਨੈਟ. ਹੈਲੋ ਲੋਕਲਹੋਸਟ [127.0.0.1], ਤੁਹਾਨੂੰ ਮਿਲਣ ਲਈ ਖੁਸ਼
250-EXPN
250-VERB
250-8 ਬਿਟਸ ਮਿਮੀ
250-SIZE
250-DSN
250-ONEX
250-ਈ.ਟੀ.ਆਰ.ਐਨ
250-XUSR
250 HELP
ਸੁਭਾਗਪੂਰਨ, ਹੋਰਨਾਂ ਚੀਜ਼ਾਂ ਦੇ ਵਿੱਚ ਸਾਨੂੰ DSN ਮਿਲਦਾ ਹੈ.
DSN ਭੇਜਣ ਵਾਲੇ ਐਕਸਟੈਂਸ਼ਨਾਂ
ਅਗਲੀ ਕਮਾਂਡ ਖਾਸ ਤੌਰ ਤੇ MAIL FROM ਹੈ. DSN ਦੇ ਨਾਲ, ਇਹ ਕੋਈ ਵੱਖਰੀ ਨਹੀਂ ਹੈ. ਪਰ ਇੱਥੇ ਦੋ ਹੋਰ ਵਿਕਲਪ ਹਨ ਜੋ ਤੁਸੀਂ ਜਾਰੀ ਕਰ ਸਕਦੇ ਹੋ: RET ਅਤੇ ENVID.
RET ਚੋਣ ਦੀ ਬਜਾਏ MAIL ਦੇ ਹੁਕਮ ਵਿੱਚ ਅਸਾਨੀ ਨਾਲ ਰੱਖਿਆ ਗਿਆ ਸੀ, ਲੇਕਿਨ ਇਹ ਇੱਥੇ ਫਿੱਟ ਹੈ ਅਤੇ ਇਹ ਕਿਤੇ ਵੀ ਕਿਸੇ ਹੋਰ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ. ਡਿਲੀਵਰੀ ਅਸਫਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿਚ ਤੁਹਾਡਾ ਅਸਲ ਸੁਨੇਹਾ ਕਿੰਨਾ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਇਸਦਾ ਮਕਸਦ ਨਿਸ਼ਚਿਤ ਕਰਨਾ ਹੈ ਸਹੀ ਆਰਗੂਮੈਂਟਾਂ ਫੁਲ ਅਤੇ HDRS ਹਨ ਸਾਬਕਾ ਦਾ ਅਰਥ ਹੈ ਕਿ ਪੂਰਾ ਸੁਨੇਹਾ ਗਲਤੀ ਸੁਨੇਹੇ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਐਚਡੀਆਰਐਸ ਸਰਵਰ ਨੂੰ ਸਿਰਫ਼ ਫੇਲ੍ਹ ਹੋਏ ਮੇਲ ਦੇ ਸਿਰਲੇਖ ਵਾਪਸ ਕਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਦਿੰਦੀ ਹੈ. ਜੇ RET ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਹੈ, ਇਹ ਸਰਵਰ ਤੇ ਹੈ ਕਿ ਕੀ ਕਰਨਾ ਹੈ. ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਐਚਡੀਆਰਐਸ ਮੂਲ ਮੁੱਲ ਹੋਵੇਗਾ.
ENVID ਅਸਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲੇ ਨਾਲ ਸਬੰਧਿਤ ਹੈ ਕਿਉਂਕਿ ਉਹ (ਜਾਂ ਨਹੀਂ) ਉਸਦਾ ਈਮੇਲ ਕਲਾਇਟ ਕੇਵਲ ਉਹ ਹੀ ਹੋਵੇਗਾ ਜੋ ਸਾਨੂੰ ਇਹ ਲਿਫਾਫੇ ਪਛਾਣਕਰਤਾ ਬਣਾਉਂਦਾ ਹੈ. ਇਸਦਾ ਮਕਸਦ ਹੈ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਇਹ ਦੱਸਣਾ ਕਿ ਇਕ ਸੰਭਾਵੀ ਜਾਰੀ ਕੀਤੀ ਗਲਤੀ ਸੁਨੇਹਾ ਮੇਲ ਕਿੱਥੇ ਹੈ. ਇਸ ਆਈਡੀ ਦੇ ਫਾਰਮੈਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲੇ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ. ਅਸੀਂ ਆਪਣੀ ਉਦਾਹਰਨ ਵਿੱਚ ਏਨਿੀਵੀਆਈਡੀ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਾਂਗੇ (ਕਲਪਣਾ!):
ਮੇਲ ਤੋਂ: sender@example.com RET = HDRS
250 sender@example.com ... ਸਿਸਟਰ ਠੀਕ ਹੈ
ਜ਼ਾਹਰਾ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਸਿਰਲੇਖ ਵਾਪਸ ਆਪਣੇ DSN ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ.
DSN ਪ੍ਰਾਪਤ ਕਰਤਾ ਐਕਸਟੈਂਸ਼ਨਾਂ
RCPT TO: ਦੇ ਨਾਲ ਨਾਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦਾ ਨਿਰਪੱਖ ਸ਼ੇਅਰ ਵੀ ਮਿਲਦਾ ਹੈ: NOTIFY ਅਤੇ ORCPT
ਨੋਟਿਸ DSN ਦਾ ਅਸਲੀ ਦਿਲ ਹੈ ਇਹ ਸਰਵਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਡਲਿਵਰੀ ਸਥਿਤੀ ਸੂਚਨਾ ਕਦੋਂ ਭੇਜੀ ਜਾਵੇ. ਪਹਿਲੀ ਸੰਭਵ ਮੁੱਲ ਉਹ ਕਦੇ ਨਹੀਂ ਹੁੰਦਾ ਭਾਵ ਕਿਸੇ ਵੀ ਹਾਲਾਤ ਵਿੱਚ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਇੱਕ DSN ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ DSN ਬਗੈਰ ਸੰਭਵ ਨਹੀਂ ਸੀ. ਫਿਰ ਉੱਥੇ ਸਫਲਤਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਸੂਚਿਤ ਕਰੇਗੀ ਜਦੋਂ ਤੁਹਾਡੀ ਮੇਲ ਉਸ ਦੇ ਮੰਜ਼ਿਲ ਤੇ ਉਗਰੀ ਜਾਵੇਗੀ. ਅਸਫਲਤਾ SUCCESS ਦਾ ਹਮਰੁਤਬਾ ਹੈ (!): ਇੱਕ ਡੀ ਐੱਸ ਐਨ ਪਹੁੰਚਦਾ ਹੈ ਜੇ ਪਹੁੰਚਣ ਦੇ ਦੌਰਾਨ ਇੱਕ ਅੌਰਤ ਆ ਜਾਂਦਾ ਹੈ. ਆਖਰੀ ਵਿਕਲਪ ਡੈਰੀ ਹੈ: ਤੁਹਾਨੂੰ ਸਪੁਰਦ ਕੀਤਾ ਜਾਵੇਗਾ ਜੇਕਰ ਡਿਲਿਵਰੀ ਵਿੱਚ ਕੋਈ ਅਸਧਾਰਨ ਵਿਰਾਮ ਹੁੰਦਾ ਹੈ, ਪਰ ਅਸਲ ਡਿਲੀਵਰੀ ਦਾ ਨਤੀਜਾ (ਸਫ਼ਲਤਾ ਜਾਂ ਅਸਫਲਤਾ) ਦਾ ਹਾਲੇ ਫੈਸਲਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ. ਕਦੇ ਵੀ ਇਕੋ ਦਲੀਲ ਹੋਣੀ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ ਜੇਕਰ ਇਹ ਨਿਸ਼ਚਿਤ ਕੀਤੀ ਗਈ ਹੋਵੇ, ਬਾਕੀ ਤਿੰਨ ਇੱਕ ਸੂਚੀ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋ ਸਕਦੇ ਹਨ, ਇੱਕ ਕਾਮੇ ਦੁਆਰਾ ਸੀਮਿਤ ਸਫਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਇੱਕ ਬਹੁਤ ਮਜ਼ਬੂਤ ਟੀਮ ਲਈ ਮਿਲ ਕੇ (!), ਤੁਹਾਨੂੰ (ਲਗਭਗ) ਕਿਸੇ ਵੀ ਕੇਸ ਵਿੱਚ ਤੁਹਾਨੂੰ ਦੱਸ ਰਿਹਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਮੇਲ ਨੂੰ ਕੀ ਹੋਇਆ ਹੈ
ORCPT ਦਾ ਉਦੇਸ਼ ਇੱਕ ਈਮੇਲ ਸੰਦੇਸ਼ ਦੀ ਅਸਲ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਜੇਕਰ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਪਤੇ 'ਤੇ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਇਸ ਵਿਕਲਪ ਲਈ ਦਲੀਲ ਇਹ ਹੈ ਕਿ ਉਹ ਅਸਲੀ ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਈ-ਮੇਲ ਐਡਰੈੱਸ ਕਿਸਮ ਦੇ ਨਾਲ ਹੈ. ਐਡਰੈੱਸ ਦੀ ਕਿਸਮ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ, ਇਕ ਸੈਮੀਕੋਲਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਆਖਰਕਾਰ ਪਤਾ ਹੁੰਦਾ ਹੈ. ਉਦਾਹਰਣ ਲਈ:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਸਹੀ (ਕਤਾਰ ਹੋਵੇਗਾ)
ਇਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਡੇਟਾ ਨੂੰ ਜਾਣਦੇ ਹਾਂ ਅਤੇ ਅਖੀਰ, ਉਮੀਦ ਹੈ ਕਿ ਇੱਕ ਡਿਲਿਵਰੀ ਸਟੈਟਸ ਨੋਟੀਫਿਕੇਸ਼ਨ ਤੁਹਾਨੂੰ ਸਫਲਤਾ ਦੀ ਸੂਚਨਾ ਦੇਵੇਗੀ.
ਕੀ DSN ਕੰਮ ਕਰਦਾ ਹੈ?
ਬੇਸ਼ਕ, ਇਹ ਸਭ ਸੁੰਦਰਤਾ ਅਤੇ ਸਮਝ ਸਿਰਫ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰੇਗੀ ਜੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਦੀ ਸਹਾਇਤਾ DSN ਦੇ ਮੇਲ ਟਰਾਂਸਪੋਰਟ ਏਜੰਟ ਕੁਝ ਦਿਨ ਉਹ ਕਰੇਗਾ