Rjochtsje Postfix op in mailrelay, net op de webproxy

relayhost = proxy.example.net:3128 liket oannimlik oant de beide einen begjinne te praten. Postfix ferwachtet in SMTP-pear. In webproxy op 3128 ferwachtet in HTTP-proxyoanfraach. Gjin fan beide krijt it petear dêr't it op wachte.

As it netwurk in goedkarde mailrelay leveret, konfigurearje dan dat SMTP-tsjinst ynstee. In typyske foarm is:

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

De hostnamme en de poarte binne foarbylden. Heakjes ûnderdrukke de MX-syktocht foar dy relaynamme. Se foegje gjin HTTP CONNECT, TLS of autentikaasje ta. Konfigurearje de frege submission-, SASL- en TLS-ynstellingen fan de relay apart.

De beide akkounts kinne ek ferskille. In wachtwurd dat de webproxy akseptearret is net automatysk in mailsubmission-identiteit, en de relay kin in ôfstjoerder noch ôfwize nei't de ferbining akseptearre is.

Wat as it iennichste goedkarde paad in tunnel is?

In HTTP-proxy kin SMTP troch CONNECT drage as it de bestimming en de poarte tastiet. Dat makket net dat in willekeurige SMTP-klant CONNECT generearret. In ark as curl hat in eksplisite proxy-tunnelopsje; de relayhost fan Postfix ynstelle is in oare ynterface.

In fêste SSH-oerdracht of in doelboud lokale transportadapter kin ien goedkarde SMTP-tsjinst as in lokaal TCP-einpunt bleatstelle. Yn dat ûntwerp praat Postfix SMTP mei it einpunt, en de adapter leveret it oare transport. Hâld it beheind en bewarje de TLS-identiteit fan de bedoelde mailserver: it feroarjen fan it ferbiningsadres nei loopback kin namme-basearre sertifikaatbelied beynfloedzje.

Ferken it mailrelay as dat de tsjinst is dy't de netwurkoperator leveret. It jout wachtrige, ôfstjoerderbelied en leveringsflaters in SMTP-begrypende thús. In webproxy-ynstelling allinnich leveret gjin fan dy mailfunksjes.