Postfix ਨੂੰ ਮੇਲ ਰੀਲੇ ਵੱਲ ਭੇਜੋ, ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਵੱਲ ਨਹੀਂ

relayhost = proxy.example.net:3128 ਉਦੋਂ ਤੱਕ ਭਰੋਸੇਯੋਗ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਦੋਵੇਂ ਸਿਰੇ ਗੱਲ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ। Postfix SMTP ਸਾਥੀ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। 3128 ’ਤੇ ਵੈੱਬ ਪ੍ਰੌਕਸੀ HTTP ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ। ਕਿਸੇ ਨੂੰ ਵੀ ਉਹ ਗੱਲਬਾਤ ਨਹੀਂ ਮਿਲਦੀ ਜਿਸਦੀ ਉਮੀਦ ਸੀ।

ਜੇ ਨੈੱਟਵਰਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮੇਲ ਰੀਲੇ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਬਜਾਏ ਉਹ SMTP ਸੇਵਾ ਸੰਰਚਿਤ ਕਰੋ। ਆਮ ਰੂਪ ਇਹ ਹੈ:

relayhost = [smtp-relay.example.net]:587

ਹੋਸਟਨਾਮ ਅਤੇ ਪੋਰਟ ਉਦਾਹਰਨਾਂ ਹਨ। ਬਰੈਕਟ ਉਸ ਰੀਲੇ ਨਾਮ ਲਈ MX ਖੋਜ ਨੂੰ ਦਬਾਉਂਦੇ ਹਨ। ਉਹ HTTP CONNECT, TLS ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਜੋੜਦੇ। ਰੀਲੇ ਦੀਆਂ ਲੋੜੀਂਦੀਆਂ submission, SASL ਅਤੇ TLS ਸੈਟਿੰਗਾਂ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸੰਰਚਿਤ ਕਰੋ।

ਦੋਵੇਂ ਖਾਤੇ ਵੱਖਰੇ ਵੀ ਹੋ ਸਕਦੇ ਹਨ। ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਵੱਲੋਂ ਸਵੀਕਾਰ ਕੀਤਾ ਪਾਸਵਰਡ ਆਪਣੇ ਆਪ ਮੇਲ submission ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਰੀਲੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇ ਇੱਕੋ-ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਾਹ ਇੱਕ ਟਨਲ ਹੋਵੇ ਤਾਂ?

HTTP ਪ੍ਰੌਕਸੀ SMTP ਨੂੰ CONNECT ਰਾਹੀਂ ਲੈ ਜਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਉਹ ਮੰਜ਼ਿਲ ਅਤੇ ਪੋਰਟ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇਸ ਨਾਲ ਕੋਈ ਵੀ SMTP ਕਲਾਇੰਟ CONNECT ਨਹੀਂ ਬਣਾਉਂਦਾ। curl ਵਰਗੇ ਸਾਧਨ ਵਿੱਚ ਸਪਸ਼ਟ ਪ੍ਰੌਕਸੀ-ਟਨਲ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ; Postfix ਦਾ relayhost ਸੈੱਟ ਕਰਨਾ ਵੱਖਰਾ ਇੰਟਰਫੇਸ ਹੈ।

ਇੱਕ ਸਥਿਰ SSH ਫਾਰਵਰਡ ਜਾਂ ਉਦੇਸ਼-ਨਿਰਮਿਤ ਸਥਾਨਕ ਆਵਾਜਾਈ ਅਡੈਪਟਰ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ SMTP ਸੇਵਾ ਨੂੰ ਸਥਾਨਕ TCP ਅੰਤ ਬਿੰਦੂ ਵਜੋਂ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ। ਉਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ Postfix ਅੰਤ ਬਿੰਦੂ ਨਾਲ SMTP ਬੋਲਦਾ ਹੈ, ਅਤੇ ਅਡੈਪਟਰ ਦੂਜੀ ਆਵਾਜਾਈ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਸੀਮਿਤ ਰੱਖੋ ਅਤੇ ਇੱਛਤ ਮੇਲ ਸਰਵਰ ਦੀ TLS ਪਛਾਣ ਬਚਾਓ: ਕਨੈਕਸ਼ਨ ਪਤਾ loopback ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਨਾਮ-ਆਧਾਰਿਤ ਸਰਟੀਫਿਕੇਟ ਨੀਤੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ।

ਜਦੋਂ ਨੈੱਟਵਰਕ ਆਪਰੇਟਰ ਵੱਲੋਂ ਦਿੱਤੀ ਸੇਵਾ ਮੇਲ ਰੀਲੇ ਹੋਵੇ ਤਾਂ ਉਸਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਇਹ ਕਤਾਰ, ਭੇਜਣ ਵਾਲੇ ਦੀ ਨੀਤੀ ਅਤੇ ਡਿਲਿਵਰੀ ਗਲਤੀਆਂ ਨੂੰ SMTP ਸਮਝਣ ਵਾਲਾ ਘਰ ਦਿੰਦੀ ਹੈ। ਕੇਵਲ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਇਹਨਾਂ ਮੇਲ ਕਾਰਜਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਦਿੰਦੀ।