relayhost = proxy.example.net:3128 sinesgarria dirudi bi muturrak hitz egiten hasi arte. Postfix SMTP kide baten zain dago. 3128ko web proxy batek HTTP proxy eskaeraren zain dago. Batak ere ez du espero zuen elkarrizketa jasotzen.

Sareak onartutako posta-errele bat eskaintzen badu, konfiguratu SMTP zerbitzu hori horren ordez. Ohiko forma hau da:

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

Ostalariaren izena eta portua adibideak dira. Parentesi karratuek errele izen horretarako MX bilaketa ezabatzen dute. Ez dute HTTP CONNECT, TLS edo autentifikaziorik gehitzen. Konfiguratu erreleak eskatzen dituen submission, SASL eta TLS ezarpenak bereizita.

Bi kontuak desberdinak ere izan daitezke. Web proxyak onartzen duen pasahitza ez da automatikoki posta bidaltzeko kredentziala, eta erreleak bidaltzaile bat baztertu dezake konexioa onartu ondoren ere.

Zer gertatzen da onartutako bide bakarra tunel bat bada?

HTTP proxy batek SMTP CONNECT bidez eraman dezake helmuga eta portua onartzen dituenean. Horrek ez du edozein SMTP bezero CONNECT sortzera behartzen. curl bezalako tresna batek proxy tunelaren aukera esplizitua du; Postfixen relayhost ezartzea beste interfaze bat da.

SSH birbidaltze finko batek edo helburu jakin baterako tokiko garraio egokitzaile batek onartutako SMTP zerbitzu bat tokiko TCP amaiera-puntu gisa erakutsi dezake. Diseinu horretan Postfixek SMTP hitz egiten du amaiera-puntuarekin, eta egokitzaileak beste garraioa ematen du. Mantendu murriztuta eta gorde aurreikusitako posta-zerbitzariaren TLS identitatea: konexio-helbidea loopback-era aldatzeak izenean oinarritutako ziurtagiri-politikari eragin diezaioke.

Hobetsi posta-errelea sare-operadoreak ematen duen zerbitzua denean. Ilarari, bidaltzaile-politikari eta entrega-erroreei SMTP ulertzen duen etxea ematen die. Web proxyaren ezarpenak bakarrik ez du posta-funtzio horietako bat ere ematen.

Erlazionatutako artikuluak