ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, MTA-STS ਈਮੇਲਾਂ ਨੂੰ ਇੰਟਰਸੈਪਸ਼ਨ (ਜਿਵੇਂ ਕਿ ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲੇ ਉਰਫ MitM) ਤੋਂ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਜਦੋਂ ਮੇਲ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਈਮੇਲ ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਵਿਰਾਸਤੀ ਆਰਕੀਟੈਕਚਰਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁਕਾਬਲਤਨ ਹਾਲੀਆ ਮਿਆਰੀ RFC 8461 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ। Mail.ru ਇਸ ਮਿਆਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ RuNet 'ਤੇ ਪਹਿਲੀ ਪ੍ਰਮੁੱਖ ਮੇਲ ਸੇਵਾ ਹੈ। ਅਤੇ ਇਸ ਨੂੰ ਕੱਟ ਦੇ ਅਧੀਨ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ.

MTA-STS ਕਿਹੜੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ?

ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਈਮੇਲ ਪ੍ਰੋਟੋਕੋਲ (SMTP, POP3, IMAP) ਨੇ ਸਪਸ਼ਟ ਟੈਕਸਟ ਵਿੱਚ ਜਾਣਕਾਰੀ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀ, ਜਿਸ ਨਾਲ ਇਸਨੂੰ ਰੋਕਣਾ ਸੰਭਵ ਹੋ ਗਿਆ, ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਇੱਕ ਸੰਚਾਰ ਚੈਨਲ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਉਪਭੋਗਤਾ ਤੋਂ ਦੂਜੇ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਪੱਤਰ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਵਿਧੀ ਕੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਇੱਕ MitM ਹਮਲਾ ਉਨ੍ਹਾਂ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਸੰਭਵ ਸੀ ਜਿੱਥੇ ਮੇਲ ਘੁੰਮਦਾ ਹੈ।

RFC 8314 ਨੂੰ ਮੇਲ ਉਪਭੋਗਤਾ ਐਪਲੀਕੇਸ਼ਨ (MUA) ਅਤੇ ਮੇਲ ਸਰਵਰ ਵਿਚਕਾਰ TLS ਦੀ ਵਰਤੋਂ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਸਰਵਰ ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਮੇਲ ਐਪਲੀਕੇਸ਼ਨਾਂ RFC 8314 ਦੇ ਅਨੁਕੂਲ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਅਤੇ ਮੇਲ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਮੈਨ-ਇਨ-ਦਿ-ਮਿਡਲ ਹਮਲਿਆਂ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ (ਵੱਡੇ ਪੱਧਰ 'ਤੇ) ਖਤਮ ਕਰ ਦਿੱਤਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕੀਤੇ ਅਭਿਆਸਾਂ (RFC 8314 ਦੁਆਰਾ ਮਾਨਕ) ਦਾ ਪਾਲਣ ਕਰਨਾ ਉਪਭੋਗਤਾ ਦੇ ਨੇੜੇ ਹਮਲੇ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ:

Mail.ru ਮੇਲ ਸਰਵਰਾਂ ਨੇ ਸਟੈਂਡਰਡ ਨੂੰ ਅਪਣਾਏ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ RFC 8314 ਦੀ ਪਾਲਣਾ ਕੀਤੀ; ਅਸਲ ਵਿੱਚ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤੇ ਅਭਿਆਸਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਹੋਰ ਕੁਝ ਵੀ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਪਰ, ਜੇਕਰ ਤੁਹਾਡਾ ਮੇਲ ਸਰਵਰ ਅਜੇ ਵੀ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸ ਮਿਆਰ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਓ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਘੱਟੋ-ਘੱਟ ਤੁਹਾਡੇ ਕੁਝ ਉਪਭੋਗਤਾ ਬਿਨਾਂ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਮੇਲ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਤੁਸੀਂ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹੋ।

ਮੇਲ ਕਲਾਇੰਟ ਹਮੇਸ਼ਾ ਉਸੇ ਸੰਸਥਾ ਦੇ ਇੱਕੋ ਮੇਲ ਸਰਵਰ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਤੁਸੀਂ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੁੜਨ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਗੈਰ-ਸੁਰੱਖਿਅਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਜੁੜਨਾ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਬਣਾ ਸਕਦੇ ਹੋ (ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ RFC 8314 ਦੀ ਲੋੜ ਹੈ)। ਇਹ ਕਈ ਵਾਰ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ, ਪਰ ਸੰਭਵ ਹੁੰਦਾ ਹੈ। ਮੇਲ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਅਜੇ ਵੀ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ। ਸਰਵਰ ਵੱਖ-ਵੱਖ ਸੰਸਥਾਵਾਂ ਨਾਲ ਸਬੰਧਤ ਹਨ ਅਤੇ ਅਕਸਰ "ਸੈੱਟ ਅਤੇ ਭੁੱਲੋ" ਮੋਡ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਇੱਕ ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਬਦਲਣਾ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ। SMTP ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ STARTTLS ਐਕਸਟੈਂਸ਼ਨ ਪ੍ਰਦਾਨ ਕੀਤੀ ਹੈ, ਜੋ ਸਰਵਰਾਂ ਨੂੰ TLS 'ਤੇ ਸਵਿਚ ਕਰਨ ਲਈ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪਰ ਇੱਕ ਹਮਲਾਵਰ ਜਿਸ ਕੋਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ, ਇਸ ਕਮਾਂਡ ਲਈ ਸਮਰਥਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ "ਕੱਟ" ਸਕਦਾ ਹੈ ਅਤੇ ਸਰਵਰਾਂ ਨੂੰ ਇੱਕ ਪਲੇਨ ਟੈਕਸਟ ਪ੍ਰੋਟੋਕੋਲ (ਅਖੌਤੀ ਡਾਊਨਗ੍ਰੇਡ ਅਟੈਕ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਚਾਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਸੇ ਕਾਰਨ ਕਰਕੇ, STARTTLS ਆਮ ਤੌਰ 'ਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ ਹੈ (ਇੱਕ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਸਰਟੀਫਿਕੇਟ ਪੈਸਿਵ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਟੈਕਸਟ ਵਿੱਚ ਸੁਨੇਹਾ ਭੇਜਣ ਨਾਲੋਂ ਕੋਈ ਮਾੜਾ ਨਹੀਂ ਹੈ)। ਇਸਲਈ, STARTTLS ਸਿਰਫ਼ ਪੈਸਿਵ ਇਵਸਡ੍ਰੌਪਿੰਗ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

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

ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਕਿਉਂ? MTA-STS ਕੇਵਲ ਤਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਦੋਵੇਂ ਧਿਰਾਂ ਨੇ ਇਸ ਮਿਆਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਧਿਆਨ ਰੱਖਿਆ ਹੈ, ਅਤੇ MTA-STS ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ ਜਿਸ ਵਿੱਚ ਇੱਕ ਹਮਲਾਵਰ ਜਨਤਕ CAs ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਇੱਕ ਵੈਧ ਡੋਮੇਨ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ।

MTA-STS ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ

1. ਮੇਲ ਸਰਵਰ 'ਤੇ ਇੱਕ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਲ STARTTLS ਸਮਰਥਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ। 
2. HTTPS ਦੁਆਰਾ MTA-STS ਨੀਤੀ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ; ਇੱਕ ਵਿਸ਼ੇਸ਼ mta-sts ਡੋਮੇਨ ਅਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਜਾਣੇ-ਪਛਾਣੇ ਮਾਰਗ ਨੂੰ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ https://mta-sts.mail.ru/.well-known/mta-sts.txt. ਨੀਤੀ ਵਿੱਚ ਮੇਲ ਸਰਵਰਾਂ (mx) ਦੀ ਇੱਕ ਸੂਚੀ ਸ਼ਾਮਲ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਇਸ ਡੋਮੇਨ ਲਈ ਮੇਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਹੈ।
3. ਨੀਤੀ ਸੰਸਕਰਣ ਦੇ ਨਾਲ DNS ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ TXT ਰਿਕਾਰਡ _mta-sts ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਨੀਤੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਇਸ ਐਂਟਰੀ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਇਹ ਨੀਤੀ ਦੀ ਮੁੜ ਪੁੱਛਗਿੱਛ ਕਰਨ ਲਈ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਸੰਕੇਤ ਕਰਦਾ ਹੈ)। ਉਦਾਹਰਣ ਲਈ, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

ਭੇਜਣ ਵਾਲਾ

ਭੇਜਣ ਵਾਲਾ _mta-sts DNS ਰਿਕਾਰਡ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਹ ਉਪਲਬਧ ਹੈ, ਤਾਂ HTTPS (ਸਰਟੀਫਿਕੇਟ ਦੀ ਜਾਂਚ) ਰਾਹੀਂ ਇੱਕ ਨੀਤੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ ਨੀਤੀ ਕੈਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਇਸ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਾਂ DNS ਰਿਕਾਰਡ ਨੂੰ ਧੋਖਾ ਦਿੰਦਾ ਹੈ)।

ਮੇਲ ਭੇਜਣ ਵੇਲੇ, ਇਹ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ:

• ਜਿਸ ਸਰਵਰ ਨੂੰ ਮੇਲ ਡਿਲੀਵਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਹ ਪਾਲਿਸੀ ਵਿੱਚ ਹੈ;
• ਸਰਵਰ TLS (STARTTLS) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੇਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਹੈ।

MTA-STS ਦੇ ਫਾਇਦੇ

MTA-STS ਉਹਨਾਂ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ (SMTP+STARTTLS, HTTPS, DNS) ਵਿੱਚ ਲਾਗੂ ਹਨ। ਪ੍ਰਾਪਤਕਰਤਾ ਵਾਲੇ ਪਾਸੇ ਲਾਗੂ ਕਰਨ ਲਈ, ਸਟੈਂਡਰਡ ਲਈ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਸੌਫਟਵੇਅਰ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

MTA-STS ਦੇ ਨੁਕਸਾਨ

ਵੈੱਬ ਅਤੇ ਮੇਲ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵੈਧਤਾ, ਨਾਮਾਂ ਦੇ ਪੱਤਰ ਵਿਹਾਰ ਅਤੇ ਸਮੇਂ ਸਿਰ ਨਵਿਆਉਣ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਮੇਲ ਡਿਲੀਵਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕੇਗਾ।

ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ, MTA-STS ਨੀਤੀਆਂ ਲਈ ਸਮਰਥਨ ਵਾਲਾ MTA ਲੋੜੀਂਦਾ ਹੈ; ਵਰਤਮਾਨ ਵਿੱਚ, MTA-STS MTA ਵਿੱਚ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ।

MTA-STS ਭਰੋਸੇਯੋਗ ਰੂਟ CAs ਦੀ ਸੂਚੀ ਵਰਤਦਾ ਹੈ।

MTA-STS ਉਹਨਾਂ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ ਜਿਸ ਵਿੱਚ ਹਮਲਾਵਰ ਇੱਕ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਰਵਰ ਦੇ ਨੇੜੇ MitM ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਪਾਰਦਰਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਜਿਹੇ ਹਮਲੇ ਦਾ ਪਤਾ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਆਮ ਤੌਰ 'ਤੇ, MTA-STS ਟ੍ਰੈਫਿਕ ਰੁਕਾਵਟ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਨਹੀਂ ਕਰਦਾ.

ਆਖਰੀ ਦੋ ਪੁਆਇੰਟ SMTP (RFC 7672) ਲਈ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੇ DANE ਸਟੈਂਡਰਡ ਨਾਲੋਂ MTA-STS ਨੂੰ ਘੱਟ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਵਧੇਰੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ, ਯਾਨੀ. MTA-STS ਲਈ ਇਸ ਗੱਲ ਦੀ ਘੱਟ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਟੈਂਡਰਡ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਕਾਰਨ ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਪੱਤਰ ਡਿਲੀਵਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਪ੍ਰਤੀਯੋਗੀ ਮਿਆਰ - DANE

DANE ਸਰਟੀਫਿਕੇਟ ਜਾਣਕਾਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ DNSSEC ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਹਰੀ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀਆਂ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਜੋ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਪਰ DNSSEC ਦੀ ਵਰਤੋਂ ਅਕਸਰ ਤਕਨੀਕੀ ਅਸਫਲਤਾਵਾਂ ਵੱਲ ਖੜਦੀ ਹੈ, ਕਈ ਸਾਲਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਅੰਕੜਿਆਂ ਦੇ ਅਧਾਰ 'ਤੇ (ਹਾਲਾਂਕਿ DNSSEC ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਇਸਦੇ ਤਕਨੀਕੀ ਸਮਰਥਨ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਕਾਰਾਤਮਕ ਰੁਝਾਨ ਹੈ)। ਪ੍ਰਾਪਤਕਰਤਾ ਵਾਲੇ ਪਾਸੇ SMTP ਵਿੱਚ DANE ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, DNS ਜ਼ੋਨ ਲਈ DNSSEC ਦੀ ਮੌਜੂਦਗੀ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ DANE ਲਈ NSEC/NSEC3 ਲਈ ਸਹੀ ਸਮਰਥਨ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਸ ਨਾਲ DNSSEC ਵਿੱਚ ਪ੍ਰਣਾਲੀਗਤ ਸਮੱਸਿਆਵਾਂ ਹਨ।

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

DANE ਅਤੇ MTA-STS ਇੱਕ ਦੂਜੇ ਨਾਲ ਟਕਰਾਅ ਨਹੀਂ ਕਰਦੇ ਅਤੇ ਇਕੱਠੇ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।

Mail.ru ਮੇਲ ਵਿੱਚ MTA-STS ਸਹਾਇਤਾ ਨਾਲ ਕੀ ਹੈ?

Mail.ru ਪਿਛਲੇ ਕੁਝ ਸਮੇਂ ਤੋਂ ਸਾਰੇ ਪ੍ਰਮੁੱਖ ਡੋਮੇਨਾਂ ਲਈ ਇੱਕ MTA-STS ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਸਟੈਂਡਰਡ ਦੇ ਗਾਹਕ ਹਿੱਸੇ ਨੂੰ ਲਾਗੂ ਕਰ ਰਹੇ ਹਾਂ। ਲਿਖਣ ਦੇ ਸਮੇਂ, ਨੀਤੀਆਂ ਨੂੰ ਇੱਕ ਗੈਰ-ਬਲੌਕਿੰਗ ਮੋਡ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜੇ ਡਿਲੀਵਰੀ ਇੱਕ ਨੀਤੀ ਦੁਆਰਾ ਬਲੌਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪਾਲਿਸੀਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ "ਸਪੇਅਰ" ਸਰਵਰ ਦੁਆਰਾ ਪੱਤਰ ਡਿਲੀਵਰ ਕੀਤਾ ਜਾਵੇਗਾ), ਫਿਰ ਬਲਾਕਿੰਗ ਮੋਡ ਨੂੰ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਆਊਟਗੋਇੰਗ SMTP ਟ੍ਰੈਫਿਕ, ਹੌਲੀ-ਹੌਲੀ 100% ਟ੍ਰੈਫਿਕ ਲਈ ਇਹ ਨੀਤੀਆਂ ਲਾਗੂ ਕਰਨਾ ਸਮਰਥਿਤ ਹੈ।

ਹੋਰ ਕੌਣ ਮਿਆਰ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ?

ਹੁਣ ਤੱਕ, MTA-STS ਨੀਤੀਆਂ ਲਗਭਗ 0.05% ਸਰਗਰਮ ਡੋਮੇਨਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ, ਪਰ, ਫਿਰ ਵੀ, ਉਹ ਪਹਿਲਾਂ ਹੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਮੇਲ ਟ੍ਰੈਫਿਕ ਦੀ ਰੱਖਿਆ ਕਰਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਸਟੈਂਡਰਡ ਨੂੰ ਪ੍ਰਮੁੱਖ ਖਿਡਾਰੀਆਂ - ਗੂਗਲ, ​​​​ਕਾਮਕਾਸਟ ਅਤੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਵੇਰੀਜੋਨ (ਏਓਐਲ, ਯਾਹੂ) ਦੁਆਰਾ ਸਮਰਥਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਕਈ ਹੋਰ ਡਾਕ ਸੇਵਾਵਾਂ ਨੇ ਘੋਸ਼ਣਾ ਕੀਤੀ ਹੈ ਕਿ ਮਿਆਰੀ ਲਈ ਸਮਰਥਨ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਇਸ ਦਾ ਮੇਰੇ 'ਤੇ ਕੀ ਅਸਰ ਪਵੇਗਾ?

ਉਦੋਂ ਤੱਕ ਨਹੀਂ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡਾ ਡੋਮੇਨ MTA-STS ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਮੇਲ ਸਰਵਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਈਮੇਲਾਂ ਨੂੰ ਰੁਕਾਵਟ ਤੋਂ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਮੈਂ MTA-STS ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਾਂ?

ਪ੍ਰਾਪਤਕਰਤਾ ਵਾਲੇ ਪਾਸੇ MTA-STS ਸਮਰਥਨ

ਇਹ ਨੀਤੀ ਨੂੰ HTTPS ਅਤੇ DNS ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ, MTA ਵਿੱਚ STARTTLS ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ CAs (ਆਓ ਐਨਕ੍ਰਿਪਟ ਸੰਭਵ ਹੈ) ਤੋਂ ਇੱਕ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਕੌਂਫਿਗਰ ਕਰੋ (STARTTLS ਸਾਰੇ ਆਧੁਨਿਕ MTAs ਵਿੱਚ ਸਮਰਥਿਤ ਹੈ), ਵੱਲੋਂ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਸਮਰਥਨ ਨਹੀਂ। MTA ਲੋੜੀਂਦਾ ਹੈ।

ਕਦਮ ਦਰ ਕਦਮ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

1. ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਰਹੇ MTA ਵਿੱਚ STARTTLS ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ (ਪੋਸਟਫਿਕਸ, ਐਗਜ਼ਿਮ, ਸੇਂਡਮੇਲ, ਮਾਈਕਰੋਸਾਫਟ ਐਕਸਚੇਂਜ, ਆਦਿ)।
2. ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਵੈਧ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਰਤ ਰਹੇ ਹੋ (ਇੱਕ ਭਰੋਸੇਯੋਗ CA ਦੁਆਰਾ ਜਾਰੀ ਕੀਤਾ ਗਿਆ, ਮਿਆਦ ਪੁੱਗਿਆ ਨਹੀਂ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਦਾ ਵਿਸ਼ਾ MX ਰਿਕਾਰਡ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡੋਮੇਨ ਲਈ ਮੇਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ)।
3. ਇੱਕ TLS-RPT ਰਿਕਾਰਡ ਕੌਂਫਿਗਰ ਕਰੋ ਜਿਸ ਰਾਹੀਂ ਨੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਰਿਪੋਰਟਾਂ ਡਿਲੀਵਰ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ (ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਜੋ TLS ਰਿਪੋਰਟਾਂ ਭੇਜਣ ਦਾ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ)। ਉਦਾਹਰਨ ਐਂਟਰੀ (example.com ਡੋਮੇਨ ਲਈ):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   ਇਹ ਐਂਟਰੀ ਮੇਲ ਭੇਜਣ ਵਾਲਿਆਂ ਨੂੰ SMTP ਵਿੱਚ TLS ਵਰਤੋਂ ਬਾਰੇ ਅੰਕੜਾ ਰਿਪੋਰਟਾਂ ਭੇਜਣ ਲਈ ਨਿਰਦੇਸ਼ ਦਿੰਦੀ ਹੈ [email protected].

   ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਹਨ, ਕਈ ਦਿਨਾਂ ਲਈ ਰਿਪੋਰਟਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।

4. HTTPS ਉੱਤੇ MTA-STS ਨੀਤੀ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਨੀਤੀ ਨੂੰ ਸਥਾਨ ਦੁਆਰਾ CRLF ਲਾਈਨ ਟਰਮੀਨੇਟਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਟੈਕਸਟ ਫਾਈਲ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   ਉਦਾਹਰਨ ਨੀਤੀ:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   ਸੰਸਕਰਣ ਖੇਤਰ ਵਿੱਚ ਨੀਤੀ ਦਾ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹੈ (ਵਰਤਮਾਨ ਵਿੱਚ STSv1), ਮੋਡ ਨੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਮੋਡ, ਟੈਸਟਿੰਗ — ਟੈਸਟ ਮੋਡ (ਪਾਲਿਸੀ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ), ਲਾਗੂ — “ਲੜਾਈ” ਮੋਡ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ ਨੀਤੀ ਨੂੰ ਮੋਡ ਦੇ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ: ਟੈਸਟਿੰਗ, ਜੇਕਰ ਟੈਸਟ ਮੋਡ ਵਿੱਚ ਨੀਤੀ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਤੁਸੀਂ ਮੋਡ ਵਿੱਚ ਸਵਿਚ ਕਰ ਸਕਦੇ ਹੋ: ਲਾਗੂ ਕਰੋ।

   mx ਵਿੱਚ, ਸਾਰੇ ਮੇਲ ਸਰਵਰਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਦਿੱਤੀ ਗਈ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡੋਮੇਨ ਲਈ ਮੇਲ ਸਵੀਕਾਰ ਕਰ ਸਕਦੇ ਹਨ (ਹਰੇਕ ਸਰਵਰ ਕੋਲ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਸੰਰਚਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ mx ਵਿੱਚ ਦਿੱਤੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ)। Max_age ਪਾਲਿਸੀ ਦਾ ਕੈਸ਼ਿੰਗ ਸਮਾਂ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ (ਇੱਕ ਵਾਰ ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਨੀਤੀ ਲਾਗੂ ਹੋ ਜਾਵੇਗੀ ਭਾਵੇਂ ਹਮਲਾਵਰ ਇਸਦੀ ਡਿਲੀਵਰੀ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜਾਂ ਕੈਸ਼ਿੰਗ ਸਮੇਂ ਦੌਰਾਨ DNS ਰਿਕਾਰਡਾਂ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ, ਤੁਸੀਂ mta-sts DNS ਨੂੰ ਬਦਲ ਕੇ ਦੁਬਾਰਾ ਨੀਤੀ ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਲੋੜ ਦਾ ਸੰਕੇਤ ਦੇ ਸਕਦੇ ਹੋ। ਰਿਕਾਰਡ).

5. DNS ਵਿੱਚ ਇੱਕ TXT ਰਿਕਾਰਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   ਇੱਕ ਆਰਬਿਟਰਰੀ ਪਛਾਣਕਰਤਾ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਟਾਈਮਸਟੈਂਪ) ਨੂੰ id ਖੇਤਰ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਜਦੋਂ ਨੀਤੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਇਹ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਭੇਜਣ ਵਾਲਿਆਂ ਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕੈਸ਼ ਕੀਤੀ ਨੀਤੀ ਦੀ ਮੁੜ ਬੇਨਤੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਜੇ ਪਛਾਣਕਰਤਾ ਇਸ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਇੱਕ ਕੈਸ਼ ਕੀਤਾ).

ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ MTA-STS ਸਮਰਥਨ

ਹੁਣ ਤੱਕ ਇਹ ਉਸਦੇ ਨਾਲ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ... ਤਾਜ਼ਾ ਮਿਆਰੀ.

• ਐਗਜ਼ਿਮ - ਕੋਈ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ ਨਹੀਂ, ਇੱਕ ਤੀਜੀ-ਧਿਰ ਸਕ੍ਰਿਪਟ ਹੈ https://github.com/Bobberty/MTASTS-EXIM-PERL 
• ਪੋਸਟਫਿਕਸ - ਇੱਥੇ ਕੋਈ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ ਨਹੀਂ ਹੈ, ਇੱਥੇ ਇੱਕ ਤੀਜੀ-ਧਿਰ ਸਕ੍ਰਿਪਟ ਹੈ ਜੋ ਹੈਬਰੇ 'ਤੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ https://habr.com/en/post/424961/

"ਲਾਜ਼ਮੀ TLS" ਬਾਰੇ ਬਾਅਦ ਦੇ ਸ਼ਬਦ ਵਜੋਂ

ਹਾਲ ਹੀ ਵਿੱਚ, ਰੈਗੂਲੇਟਰ ਈਮੇਲ ਸੁਰੱਖਿਆ ਵੱਲ ਧਿਆਨ ਦੇ ਰਹੇ ਹਨ (ਅਤੇ ਇਹ ਇੱਕ ਚੰਗੀ ਗੱਲ ਹੈ). ਉਦਾਹਰਨ ਲਈ, DMARC ਸੰਯੁਕਤ ਰਾਜ ਵਿੱਚ ਸਾਰੀਆਂ ਸਰਕਾਰੀ ਏਜੰਸੀਆਂ ਲਈ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਵਿੱਤੀ ਖੇਤਰ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਵਧਦੀ ਜਾ ਰਹੀ ਹੈ, ਨਿਯਮਿਤ ਖੇਤਰਾਂ ਵਿੱਚ 90% ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਮਿਆਰ ਦੇ ਪ੍ਰਵੇਸ਼ ਦੇ ਨਾਲ। ਹੁਣ ਕੁਝ ਰੈਗੂਲੇਟਰਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਡੋਮੇਨਾਂ ਦੇ ਨਾਲ "ਲਾਜ਼ਮੀ TLS" ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ "ਲਾਜ਼ਮੀ TLS" ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵਿਧੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਸੈਟਿੰਗ ਅਕਸਰ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਅਸਲ ਹਮਲਿਆਂ ਤੋਂ ਘੱਟ ਤੋਂ ਘੱਟ ਸੁਰੱਖਿਆ ਵੀ ਨਹੀਂ ਕਰਦੀ ਹੈ। DANE ਜਾਂ MTA-STS ਵਰਗੀਆਂ ਵਿਧੀਆਂ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਹੈ।

ਜੇਕਰ ਰੈਗੂਲੇਟਰ ਨੂੰ ਵੱਖਰੇ ਡੋਮੇਨਾਂ ਦੇ ਨਾਲ "ਲਾਜ਼ਮੀ TLS" ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸੀਂ MTA-STS ਜਾਂ ਇਸਦੇ ਅੰਸ਼ਕ ਐਨਾਲਾਗ ਨੂੰ ਸਭ ਤੋਂ ਢੁਕਵੀਂ ਵਿਧੀ ਵਜੋਂ ਵਿਚਾਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ, ਇਹ ਹਰੇਕ ਡੋਮੇਨ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ MTA-STS ਦੇ ਕਲਾਇੰਟ ਹਿੱਸੇ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਆਉਂਦੀ ਹੈ (ਜਦੋਂ ਤੱਕ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਵਿਆਪਕ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦਾ, ਉਹ ਸੰਭਵ ਤੌਰ 'ਤੇ ਕਰਨਗੇ), ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ:

1. ਇੱਕ MTA-STS ਨੀਤੀ ਅਤੇ/ਜਾਂ DANE ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ (DANE ਤਾਂ ਹੀ ਸਮਝਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਡੋਮੇਨ ਲਈ DNSSEC ਪਹਿਲਾਂ ਹੀ ਸਮਰੱਥ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ MTA-STS), ਇਹ ਤੁਹਾਡੀ ਦਿਸ਼ਾ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਦੀ ਰੱਖਿਆ ਕਰੇਗਾ ਅਤੇ ਹੋਰ ਮੇਲ ਸੇਵਾਵਾਂ ਨੂੰ ਪੁੱਛਣ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਕਰੇਗਾ। ਤੁਹਾਡੇ ਡੋਮੇਨ ਲਈ ਲਾਜ਼ਮੀ TLS ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਜੇਕਰ ਮੇਲ ਸੇਵਾ ਪਹਿਲਾਂ ਹੀ MTA-STS ਅਤੇ/ਜਾਂ DANE ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ।
2. ਵੱਡੀਆਂ ਈਮੇਲ ਸੇਵਾਵਾਂ ਲਈ, ਹਰੇਕ ਡੋਮੇਨ ਲਈ ਵੱਖਰੀ ਟ੍ਰਾਂਸਪੋਰਟ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ MTA-STS ਦਾ "ਐਨਾਲਾਗ" ਲਾਗੂ ਕਰੋ, ਜੋ ਮੇਲ ਰੀਲੇਅ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ MX ਨੂੰ ਠੀਕ ਕਰੇਗਾ ਅਤੇ ਇਸਦੇ ਲਈ ਇੱਕ TLS ਸਰਟੀਫਿਕੇਟ ਦੀ ਲਾਜ਼ਮੀ ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਜੇਕਰ ਡੋਮੇਨ ਪਹਿਲਾਂ ਹੀ ਇੱਕ MTA-STS ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਹ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਦਰਦ ਰਹਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਪਣੇ ਆਪ ਵਿੱਚ, ਰੀਲੇਅ ਨੂੰ ਫਿਕਸ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਡੋਮੇਨ ਲਈ ਲਾਜ਼ਮੀ TLS ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਬੇਅਸਰ ਹੈ ਅਤੇ ਮੌਜੂਦਾ STARTTLS ਵਿਧੀਆਂ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਜੋੜਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com