Postfix, VPN ਅਤੇ smarthost: ਕਤਾਰ ਫਾਇਰਵਾਲ ਨਹੀਂ ਹੈ

VPN ਚੜ੍ਹਨ ਤੱਕ ਮੇਲ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਰੱਖਣਾ ਸ਼ਡਿਊਲਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਆਮ ਹੱਲ ਹੈ Postfix ਰੋਕਣਾ, main.cf ਬਦਲਣਾ ਅਤੇ ਮੁੜ ਚਾਲੂ ਕਰਨਾ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਗਲਤ ਰੂਪ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਦੋ ਲੋੜਾਂ ਮਿਲਾ ਦਿੰਦਾ ਹੈ: ਡਿਲਿਵਰੀ ਕਦੋਂ ਅਜ਼ਮਾਈ ਜਾਵੇ, ਅਤੇ ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਰਾਹ ਇਸ ਨੂੰ ਲੈ ਜਾ ਸਕਦਾ ਹੈ। ਦੂਜੀ ਫਾਇਰਵਾਲ ਦਾ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਕੋਈ Postfix ਨਿਰਦੇਸ਼ ਇਹ ਨਹੀਂ ਲੈ ਸਕਦਾ। ਦੋਵੇਂ ਵੱਖ ਹੋਣ 'ਤੇ ਹਰ ਇੱਕ ਦਾ ਛੋਟਾ ਅਤੇ ਪਰਖਣਯੋਗ ਜਵਾਬ ਹੁੰਦਾ ਹੈ।

ਰਿਲੇ ਦਾ ਟਿਕਾਣਾ ਸਥਿਰ ਰੱਖੋ, ਨੈੱਟਵਰਕ ਸੀਮਾ 'ਤੇ ਸਿੱਧੀ ਡਿਲਿਵਰੀ ਰੋਕੋ, ਅਤੇ ਉਡੀਕ ਕਤਾਰ ਨੂੰ ਕਰਨ ਦਿਓ।

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

ਰਿਲੇ Postfix ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਮੇਲ ਕਿੱਥੇ ਸੌਂਪਣਾ ਹੈ; relayhost = [smtp.corp.example]:587 ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬਰੈਕਟ ਉਸ ਅਗਲੇ ਹੌਪ ਲਈ MX-ਆਧਾਰਿਤ ਚੋਣ ਦਬਾ ਦਿੰਦੇ ਹਨ। ਰਾਹ ਕਰਨਲ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਜਾ ਸਕਦੇ ਹਨ। ਰਾਹ ਦੀ ਪਾਬੰਦੀ ਤੋਂ ਬਿਨਾਂ ਸਹੀ relayhost ਵੀ Postfix ਨੂੰ ਸਿੱਧਾ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਗਲਤ relayhost ਨਾਲ ਸਹੀ ਫਾਇਰਵਾਲ ਮੇਲ ਗਲਤ ਥਾਂ ਭੇਜਦਾ ਹੈ। ਕੋਈ ਵੀ ਦੂਜੇ ਨੂੰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਰਦਾ।

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

defer_transports ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

defer_transports ਨਾਮ ਦਿੱਤੇ ਟਰਾਂਸਪੋਰਟਾਂ ਲਈ ਸੁਨੇਹੇ ਰੋਕ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਕਤਾਰ ਦਾ ਇੱਕ ਦੌਰ ਉਨ੍ਹਾਂ ਨੂੰ ਛੂਹਣ ਤੱਕ ਕੋਈ ਡਿਲਿਵਰੀ ਯਤਨ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਸ਼ਡਿਊਲਿੰਗ ਨਿਯੰਤਰਣ ਹੈ, ਅਤੇ ਕਤਾਰ ਫਲਸ਼ ਇਸ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦਾ ਹੈ; ਇਹ ਡਿਜ਼ਾਈਨ ਹੈ, ਖਰਾਬੀ ਨਹੀਂ। master.cf ਤੋਂ ਅਸਲੀ ਟਰਾਂਸਪੋਰਟ ਨਾਮ ਵਰਤੋ, ਕਿਉਂਕਿ ਕਸਟਮ ਟਰਾਂਸਪੋਰਟ ਜਾਂ ਵੱਖਰੇ ਨਾਮ ਵਾਲਾ ਰਿਲੇ ਟਰਾਂਸਪੋਰਟ ਸਿਰਫ਼ ਇਸ ਲਈ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਸ ਦਾ ਪ੍ਰੋਗਰਾਮ SMTP ਵੀ ਬੋਲਦਾ ਹੈ। ਆਮ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਇੱਕ ਹੋਰ ਵਿਵਸਥਾ ਹੈ: fail-closed ਰਾਹ ਨਾਲ ਡਿਲਿਵਰੀ ਯਤਨ ਬਸ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਤਾਰ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਕੋਈ ਦੇਰੀ ਨਿਰਦੇਸ਼ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ।

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

ਨੈੱਟਵਰਕ ਪਰਤ 'ਤੇ ਰਾਹ ਲਾਗੂ ਕਰੋ

ਪਾਬੰਦੀ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਸੀਮਾ 'ਤੇ ਜਾਂ ਅਲੱਗ ਨੈੱਟਵਰਕ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਆਉਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਰਿਲੇ ਦੇ ਅਸਲੀ ਪਤੇ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਪੋਰਟ ਢੱਕਣੇ ਚਾਹੀਦੇ ਹਨ, IPv6 ਵੀ ਜੇ ਸਮਰੱਥ ਹੋਵੇ, ਕਿਉਂਕਿ TCP 25 ਰੋਕਣ ਵਾਲਾ ਨਿਯਮ 587 ਜਾਂ 465 'ਤੇ ਰਿਲੇ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਲੂਪਬੈਕ ਅਤੇ ਸਥਾਨਕ ਸਬਮਿਸ਼ਨ ਰਾਹ ਵੱਖ ਰੱਖੋ ਤਾਂ ਜੋ ਕਤਾਰ ਆਪ ਕੰਮ ਕਰਦੀ ਰਹੇ। ਸੁਰੰਗ ਦਾ ਰਾਹ ਗਾਇਬ ਹੋਣ ਜਾਂ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਨਾਮ ਹੇਠ ਮੁੜ ਦਿਖਣ 'ਤੇ ਨੀਤੀ ਬੰਦ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੰਟਰਫੇਸ ਦੇ ਉੱਪਰ ਆਉਣ ਦੀ ਘਟਨਾ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਰਿਲੇ ਇਸ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ। ਇਸ ਲਈ ਲਿੰਕ ਜਾਂਚ ਕੇ ਫਿਰ ਕਤਾਰ ਖਾਲੀ ਕਰਨ ਵਾਲਾ ਹੁੱਕ ਸੁਵਿਧਾ ਹੈ, ਗਾਰੰਟੀ ਨਹੀਂ: ਜਾਂਚ ਅਤੇ ਡਿਲਿਵਰੀ ਯਤਨ ਵਿਚਕਾਰ ਲਿੰਕ ਬਦਲ ਸਕਦਾ ਹੈ।

ਇੱਕ ਨਿਰਦੋਸ਼ ਸੁਨੇਹੇ ਨਾਲ ਸਾਬਤ ਕਰੋ

VPN ਬੰਦ ਹੋਣ 'ਤੇ ਇੱਕ ਨਿਰਦੋਸ਼ ਸੁਨੇਹਾ ਭੇਜੋ, ਫਿਰ ਦੇਰੀ ਦੇ ਕਾਰਨ ਅਤੇ ਕਤਾਰ ID ਲਈ postqueue -p ਵੇਖੋ। ਲੋੜੀਂਦਾ ਰਾਹ ਬਹਾਲ ਕਰੋ ਅਤੇ ਨਿਯੰਤਰਿਤ ਕਤਾਰ ਦੌਰ ਦੀ ਮੰਗ ਕਰੋ, ਦੇਖੋ ਕਿ ਸੁਨੇਹਾ ਕਿਤੇ ਹੋਰ ਨਹੀਂ ਬਲਕਿ ਰਿਲੇ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ। ਫਿਰ ਉਡਾਣ ਵਿਚਕਾਰ ਰਾਹ ਮੁੜ ਤੋੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੁਨੇਹਾ ਕਤਾਰ ਵਿੱਚ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਇਹ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਰੁਕਾਵਟ ਕਿੰਨੀ ਦੇਰ ਚੱਲ ਸਕਦੀ ਹੈ, maximal_queue_lifetime ਵੇਖੋ, ਕਿਉਂਕਿ ਜ਼ੀਰੋ ਮੁੱਲ ਦਾ ਮਤਲਬ ਇੱਕ ਯਤਨ ਹੈ, ਅਸੀਮਤ ਰੱਖ-ਰਖਾਅ ਨਹੀਂ।

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

ਰਿਲੇ, ਟਰਾਂਸਪੋਰਟ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਉਮਰ ਇਕੱਠੇ ਦਰਜ ਕਰੋ। ਉਹ ਚਾਰ ਵਿਵਸਥਾ ਦੱਸਦੇ ਹਨ; ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਅੰਦਾਜ਼ਾ ਦੱਸਦਾ ਹੈ।