relayhost = proxy.example.net:3128 tundub usutav, kuni kaks otsa rääkima hakkavad. Postfix ootab SMTP-vastaspoolt. Veebipuhverserver pordil 3128 ootab HTTP-puhverserveri päringut. Kumbki ei saa vestlust, mida ootas.

Kui võrk pakub heakskiidetud postireleet, seadista selle asemel see SMTP-teenus. Tüüpiline kuju on:

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

Hostinimi ja port on näited. Sulud suruvad selle relee nime jaoks MX-otsingu maha. Need ei lisa HTTP CONNECTi, TLSi ega autentimist. Seadista relee nõutavad submission-, SASL- ja TLS-seaded eraldi.

Need kaks kontot võivad samuti erineda. Veebipuhverserveri poolt aktsepteeritud parool ei ole automaatselt posti saatmise mandaat ja relee võib saatja pärast ühenduse vastuvõtmist ikkagi tagasi lükata.

Mis siis, kui ainus heakskiidetud tee on tunnel?

HTTP-puhverserver saab SMTP-d CONNECTi kaudu kanda, kui see lubab sihtkohta ja porti. See ei pane suvalist SMTP-klienti CONNECTi looma. Tööriistal nagu curl on selgesõnaline puhverserveri tunneli valik; Postfixi relayhosti seadistamine on teine liides.

Fikseeritud SSH-edastus või otstarbeks ehitatud kohalik transpordiadapter saab ühe heakskiidetud SMTP-teenuse kohaliku TCP-lõpp-punktina välja panna. Selles disainis räägib Postfix lõpp-punktiga SMTP-d ja adapter pakub teise transpordi. Hoia see piiratud ja säilita kavandatud postiserveri TLS-identiteet: ühenduse aadressi muutmine loopbackiks võib mõjutada nimel põhinevat sertifikaadipoliitikat.

Eelista postireleet, kui see on teenus, mida võrguoperaator pakub. See annab järjekorrale, saatjapoliitikale ja kohaletoimetamise vigadele SMTP-d mõistva kodu. Ainult veebipuhverserveri seade ei paku ühtegi neist postifunktsioonidest.

Seotud artiklid