Drejtojeni Postfix në një relay poste, jo në proxy-n e web-it

relayhost = proxy.example.net:3128 duket i besueshëm derisa dy skajet të fillojnë të flasin. Postfix pret një partner SMTP. Një proxy web në 3128 pret një kërkesë proxy HTTP. Asnjëri nuk merr bisedën që priste.

Nëse rrjeti ofron një relay poste të miratuar, konfiguroni atë shërbim SMTP në vend të tij. Një formë tipike është:

relayhost = [smtp-relay.example.net]:587

Emri i hostit dhe porta janë shembuj. Kllapat katrore shtypin kërkimin MX për atë emër relay. Ato nuk shtojnë HTTP CONNECT, TLS ose vërtetim. Konfiguroni veçmas cilësimet e kërkuara submission, SASL dhe TLS të relay-it.

Të dy llogaritë mund të jenë gjithashtu të ndryshme. Një fjalëkalim i pranuar nga proxy-i i web-it nuk është automatikisht një kredencial dërgimi poste, dhe relay-i mund të refuzojë ende një dërgues pasi të ketë pranuar lidhjen.

Po sikur e vetmja rrugë e miratuar të jetë një tunel?

Një proxy HTTP mund të mbajë SMTP përmes CONNECT kur lejon destinacionin dhe portën. Kjo nuk bën që një klient SMTP arbitrar të gjenerojë CONNECT. Një mjet si curl ka një opsion të qartë tuneli proxy; vendosja e relayhost të Postfix është një ndërfaqe tjetër.

Një përcjellje SSH fikse ose një përshtatës transporti lokal i ndërtuar posaçërisht mund të ekspozojë një shërbim SMTP të miratuar si pikë fundore TCP lokale. Në atë dizajn Postfix flet SMTP me pikën fundore, dhe përshtatësi siguron transportin tjetër. Mbani atë të kufizuar dhe ruani identitetin TLS të serverit të postës të synuar: ndryshimi i adresës së lidhjes në loopback mund të ndikojë në politikën e certifikatave të bazuar në emër.

Preferoni relay-in e postës kur ai është shërbimi që ofron operatori i rrjetit. Ai i jep radhës, politikës së dërguesit dhe gabimeve të dorëzimit një shtëpi që kupton SMTP. Vetëm cilësimi i proxy-it të web-it nuk ofron asnjë nga ato funksione poste.