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 అర్థం చేసుకునే ఇంటిని ఇస్తుంది. కేవలం వెబ్ ప్రాక్సీ సెట్టింగ్ ఈ మెయిల్ పనుల్లో ఏదీ అందించదు.