Postfix-ийг мэйл релей рүү чиглүүл, вэб прокси руу биш

relayhost = proxy.example.net:3128 хоёр тал ярьж эхлэх хүртэл үнэмшилтэй харагдана. Postfix SMTP хамтрагчийг хүлээдэг. 3128 дээрх вэб прокси HTTP прокси хүсэлтийг хүлээдэг. Аль нь ч хүлээж байсан яриаг авдаггүй.

Сүлжээ зөвшөөрөгдсөн мэйл релей өгдөг бол оронд нь тэр SMTP үйлчилгээг тохируулна уу. Ердийн хэлбэр нь:

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

Хостын нэр болон порт нь жишээ юм. Дөрвөлжин хаалт нь тухайн релей нэрэнд MX хайлтыг дардаг. Тэд HTTP CONNECT, TLS эсвэл баталгаажуулалт нэмдэггүй. Релейд шаардлагатай submission, SASL болон TLS тохиргоог тусад нь тохируулна уу.

Хоёр бүртгэл өөр байж болно. Вэб прокси хүлээн авсан нууц үг автоматаар мэйл илгээх итгэмжлэл болохгүй бөгөөд релей холболтыг хүлээн авсны дараа ч илгээгчийг татгалзаж болно.

Хэрэв цорын ганц зөвшөөрөгдсөн зам нь туннель бол?

HTTP прокси очих газар болон портыг зөвшөөрвөл SMTP-г CONNECT-ээр зөөж чадна. Энэ нь дурын SMTP клиентийг CONNECT үүсгэхэд хүргэхгүй. curl зэрэг хэрэгсэлд прокси туннелийн тодорхой сонголт байдаг; Postfix-ийн relayhost-ыг тохируулах нь өөр интерфейс юм.

Тогтмол SSH дамжуулалт эсвэл зориулалтын локал тээврийн адаптер нь нэг зөвшөөрөгдсөн SMTP үйлчилгээг локал TCP төгсгөлийн цэг болгон ил гаргаж чадна. Тэр загварт Postfix төгсгөлийн цэгтэй SMTP-ээр ярьж, адаптер нөгөө тээврийг хангадаг. Үүнийг хязгаарлагдмал байлгаж, төлөвлөсөн мэйл серверийн TLS таних тэмдгийг хадгал: холболтын хаягийг loopback болгох нь нэрэд суурилсан гэрчилгээний бодлогод нөлөөлж болно.

Сүлжээний операторын өгдөг үйлчилгээ нь мэйл релей бол түүнийг илүүд үз. Энэ нь дараалал, илгээгчийн бодлого болон хүргэлтийн алдаанд SMTP-г ойлгодог гэр өгдөг. Зөвхөн вэб прокси тохиргоо эдгээр мэйл үүргийн аль нэгийг ч өгдөггүй.