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 ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮನೆಯನ್ನು ನೀಡುತ್ತದೆ. ಕೇವಲ ವೆಬ್ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಈ ಮೇಲ್ ಕಾರ್ಯಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಒದಗಿಸುವುದಿಲ್ಲ.