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 સમજતું ઘર આપે છે. ફક્ત વેબ પ્રોક્સી સેટિંગ આ મેઇલ કાર્યોમાંથી કંઈપણ પૂરું પાડતું નથી.