Peg Postfix mod en mailrelay, ikke webproxyen
Vælg en SMTP-relay til Postfix, og skeln den fra en HTTP CONNECT-rute.
relayhost = proxy.example.net:3128 ser rimeligt ud, indtil de to ender begynder at tale sammen. Postfix forventer en SMTP-modpart. En webproxy på 3128 forventer en HTTP-proxyanmodning. Ingen af dem får den samtale, de ventede på.
Hvis netværket stiller en godkendt mailrelay til rådighed, skal du konfigurere den SMTP-tjeneste i stedet. En typisk form er:
relayhost = [smtp-relay.example.net]:587Værtsnavn og port er eksempler. Klammerne undertrykker MX-opslag for det relaynavn. De tilføjer ikke HTTP CONNECT, TLS eller godkendelse. Konfigurer relayens krævede submission-, SASL- og TLS-indstillinger separat.
De to konti kan også være forskellige. En adgangskode, som webproxyen accepterer, er ikke automatisk en mail-submission-legitimation, og relayen kan stadig afvise en afsender, efter at forbindelsen er accepteret.
Hvad hvis den eneste godkendte vej er en tunnel?
En HTTP-proxy kan bære SMTP gennem CONNECT, når den tillader destinationen og porten. Det får ikke en vilkårlig SMTP-klient til at generere CONNECT. Et værktøj som curl har en eksplicit proxy-tunnel-indstilling; at sætte Postfix' relayhost er en anden grænseflade.
En fast SSH-forward eller en specialbygget lokal transportadapter kan eksponere én godkendt SMTP-tjeneste som et lokalt TCP-endepunkt. I det design taler Postfix SMTP med endepunktet, og adapteren leverer den anden transport. Hold den begrænset, og bevar den tilsigtede mailservers TLS-identitet: at ændre forbindelsesadressen til loopback kan påvirke navnebaseret certifikatpolitik.
Foretræk mailrelayen, når det er den tjeneste, netværksoperatøren stiller til rådighed. Den giver kø, afsenderpolitik og leveringsfejl et hjem, der forstår SMTP. En webproxyindstilling alene giver ingen af disse mailfunktioner.