Îndreptați Postfix spre un releu de poștă, nu spre proxy-ul web
Alegeți un releu SMTP pentru Postfix și distingeți-l de o rută HTTP CONNECT.
relayhost = proxy.example.net:3128 pare plauzibil până când cele două capete încep să vorbească. Postfix așteaptă un partener SMTP. Un proxy web pe 3128 așteaptă o cerere de proxy HTTP. Niciunul nu primește conversația pe care o aștepta.
Dacă rețeaua oferă un releu de poștă aprobat, configurați acel serviciu SMTP în schimb. O formă tipică este:
relayhost = [smtp-relay.example.net]:587Numele gazdei și portul sunt exemple. Parantezele drepte suprimă căutarea MX pentru acel nume de releu. Ele nu adaugă HTTP CONNECT, TLS sau autentificare. Configurați separat setările submission, SASL și TLS cerute de releu.
Cele două conturi pot fi și ele diferite. O parolă acceptată de proxy-ul web nu este automat o acreditare pentru trimiterea poștei, iar releul poate respinge un expeditor chiar după ce a acceptat conexiunea.
Ce faceți dacă singura cale aprobată este un tunel?
Un proxy HTTP poate transporta SMTP prin CONNECT când permite destinația și portul. Asta nu face ca un client SMTP oarecare să genereze CONNECT. Un instrument precum curl are o opțiune explicită de tunel proxy; setarea relayhost în Postfix este altă interfață.
O redirecționare SSH fixă sau un adaptor local de transport construit special pot expune un serviciu SMTP aprobat ca punct final TCP local. În acel design Postfix vorbește SMTP cu punctul final, iar adaptorul asigură celălalt transport. Păstrați-l restricționat și conservați identitatea TLS a serverului de poștă vizat: schimbarea adresei de conectare în loopback poate afecta politica de certificate bazată pe nume.
Preferați releul de poștă când acesta este serviciul oferit de operatorul de rețea. Oferă cozii, politicii expeditorului și erorilor de livrare o casă care înțelege SMTP. Doar setarea proxy-ului web nu oferă niciuna dintre aceste funcții de poștă.