Elekeza Postfix kwa relay ya barua, si kwa proksi ya wavuti

relayhost = proxy.example.net:3128 inaonekana kuwa ya busara hadi pande mbili zianze kuzungumza. Postfix inatarajia mwenzake wa SMTP. Proksi ya wavuti kwenye 3128 inatarajia ombi la proksi ya HTTP. Hakuna anayepata mazungumzo aliyokuwa akiyasubiri.

Ikiwa mtandao unatoa relay ya barua iliyoidhinishwa, sanidi huduma hiyo ya SMTP badala yake. Umbo la kawaida ni:

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

Jina la mwenyeji na bandari ni mifano. Mabano ya mraba huzuia utafutaji wa MX kwa jina hilo la relay. Hayaongezi HTTP CONNECT, TLS au uthibitishaji. Sanidi kando mipangilio inayohitajika ya submission, SASL na TLS ya relay.

Hesabu mbili zinaweza pia kutofautiana. Nenosiri linalokubaliwa na proksi ya wavuti si hati ya utambulisho ya kutuma barua kiotomatiki, na relay bado inaweza kumkataa mtumaji baada ya kukubali muunganisho.

Je, ikiwa njia pekee iliyoidhinishwa ni handaki?

Proksi ya HTTP inaweza kubeba SMTP kupitia CONNECT inaporuhusu lengwa na bandari. Hilo halifanyi mteja wowote wa SMTP kutoa CONNECT. Chombo kama curl kina chaguo dhahiri la handaki la proksi; kuweka relayhost ya Postfix ni kiolesura kingine.

Upelekaji wa SSH uliowekwa au adapta ya usafirishaji ya ndani iliyoundwa kwa madhumuni inaweza kuonyesha huduma moja ya SMTP iliyoidhinishwa kama kituo cha mwisho cha TCP cha ndani. Katika muundo huo Postfix huzungumza SMTP na kituo cha mwisho, na adapta hutoa usafirishaji mwingine. Iweke kwa mipaka na uhifadhi utambulisho wa TLS wa seva ya barua inayokusudiwa: kubadilisha anwani ya muunganisho kuwa loopback kunaweza kuathiri sera ya vyeti inayotegemea jina.

Pendelea relay ya barua wakati hiyo ni huduma inayotolewa na mwendeshaji wa mtandao. Inatoa foleni, sera ya mtumaji na hitilafu za uwasilishaji makao yanayoelewa SMTP. Mpangilio wa proksi ya wavuti peke yake hautoi hata moja ya kazi hizo za barua.