Postfix، VPN او smarthost: قطار firewall نه دی

تر دې چې VPN پورته شي، ایمیل په قطار کې ساتل د مهالوېش ستونزه ده، او معمول حل دا دی چې Postfix ودروئ، main.cf بدل کړئ او بیا یې پیل کړئ۔ دا کار کوي، او دا غلط شکل دی، ځکه چې دوه غوښتنې یوځای کوي: چې سپارل کله هڅه شي، او کوم شبکه لاره یې وړلی شي۔ دوهمه د firewall پرېکړه ده، او هېڅ Postfix لارښوونه نشي کولی هغه وکړي۔ کله چې دواړه جلا شي، هر یو کوچنی او ازموینځای لرونکی ځواب لري۔

د ریلې منزل ټینګ وساتئ، په شبکه سرحد کې مستقیم سپارل بند کړئ، او انتظار قطار ته پرېږدئ۔

دوه غوښتنې چې خلک یې په یوه کې یوځای کوي

ریلې Postfix ته وایي چې ایمیل چېرته وسپاري؛ relayhost = [smtp.corp.example]:587 کوربه او پورټ نوموي، او بریکټونه د هغې راتلونکې ټوپ لپاره د MX پر بنسټ انتخاب غلوي۔ لاره کرنل ته وایي چې بنډلونه چېرته تللی شي۔ سم relayhost پرته د لارې محدودیت بیا هم Postfix ته اجازه ورکوي چې کله د لارښوونې جدول اجازه ورکړي مستقیم انټرنیټ ته ورسیږي، او سم firewall د غلط relayhost سره ایمیل غلط ځای ته لیږي۔ هېڅ یو بل ته اړتیا نه لري۔

د ټرانسپورټ نقشې، د هر لېږونکي بدلونونه او د بیک اپ ریلې هر یو ورته لوستل غواړي۔ ټینګ relayhost د دې ثبوت نه دی چې هر تنظیم شوی سپارلو لاره یې کاروي، او هغه بیک اپ لاره چې ریلې ته څنګه تېریږي هماغه نیمګړتیا ده په غوره پټونې کې۔

defer_transports واقعاً څه کوي

defer_transports د نومول شوو ټرانسپورټونو لپاره پیغامونه ساتي، نو تر هغې چې د قطار یو پړاو هغوی ته ورسیږي هېڅ د سپارلو هڅه نه کیږي۔ دا د مهالوېش کنټرول دی، او د قطار تازه کول پرې غالب وي؛ دا ډیزاین دی، نه نیمګړتیا۔ له master.cf څخه ریښتیني د ټرانسپورټ نومونه وکاروئ، ځکه چې ځانګړی ټرانسپورټ یا جلا نومول شوی ریلې ټرانسپورټ یوازې د دې لپاره نه پوښل کیږي چې پروګرام یې SMTP هم وایي۔ عادي بیا هڅه بله طریقه ده: د fail-closed لارې سره د سپارلو هڅې یوازې ناکامېږي او په قطار کې پاتې کیږي، پرته له کوم ځنډ لارښوونې۔

تلپاتې ناکامۍ په ادب سره نه انتظار کوي۔ خراب ترلاسه کوونکی یا رد شوی اعتبار بیرته ځي یا د سختې تېروتنې په توګه نښلي، د دې پرځای چې تر تونل راڅرګندېدو پورې کښېني، نو هغه قطار چې د ځنډول شوو ایمیلونو څخه ډک دی په اتوماتيک ډول خوندي قطار نه دی۔

په شبکه طبقه کې لاره ولګوئ

محدودیت د محلي وتلو سرحد یا د جلا شبکې نوم ځای دننه پورې اړه لري۔ باید د ریلې ریښتیني پتې، ټرانسپورټ او پورټ پوښي، په شمول IPv6 که فعال وي، ځکه چې هغه قاعده چې TCP 25 بندوي د 587 یا 465 پر ریلې لپاره هېڅ نه کوي۔ Loopback او محلي سپارلو لارې جلا وساتئ تر څو قطار پخپله کار ته دوام ورکړي۔ پالیسي باید بنده پاتې شي کله چې د تونل لاره ورکیږي یا د بل انټرفیس نوم لاندې بیا ښکاري۔

د انټرفیس پورته کېدو پېښه ثبوت نه دی چې ریلې د هغې له لارې رسیدلی شي۔ له همدې امله هغه هنګ چې لینک ګوري او بیا قطار خالي کوي اسانتیا ده، نه تضمین: لینک د ګوتې او د سپارلو هڅې ترمنځ بدلیدلی شي۔

په یو بې ضرره پیغام یې ثبوت کړئ

د VPN د ښکته حالت سره یو بې ضرره پیغام ولېږئ، بیا د ځنډ دلیل او قطار ID لپاره postqueue -p وګورئ۔ پلان شوې لاره بیرته راوګرځوئ او کنټرول شوي قطار پړاو وغواړئ، ګورئ چې پیغام د بل ځای پرځای د ریلې له لارې وځي۔ بیا په الوتنې منځ کې لاره بیا مات کړئ او تایید کړئ چې پیغام قطار ته ستنیږي۔ مخکې لدې چې پرېکړه وکړئ چې اختلال څومره دوام کولی شي maximal_queue_lifetime وګورئ، ځکه چې صفر ارزښت یوه هڅه مانا لري، نه بې حده ساتنه۔

د قطار عمر او ډیسک کارول وڅارئ۔ هغه پالیسي چې VPN ته انتظار کوي د ایمیل اختلال ته اوړي که چا ونه لیده چې له جمعې راهیسې قطار لوی ږدي۔

ریلې، ټرانسپورټ، د firewall قاعده او عمر یوځای ولیکئ۔ هغه څلور ساختار بیانوي؛ هر یو له هغوی جلا یوازې اټکل بیانوي۔