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 புரிந்த வீட்டைத் தருகிறது. வெப் ப்ராக்ஸி அமைப்பு மட்டும் இந்த மெயில் பணிகளில் எதையும் வழங்காது.